Using Panasonic TV>IP server as adapter in Tvheadend

SvenR · 2021-06-25T15:13:42+00:00

Hi, I am currently trying to use Tvheadend to stream my TV signal in my LAN. Without much success I have to say... this is what I've got: * Raspberry Pi 4...

Saen Acro

user#26890 now when you have correct freq/SR/Qam on working mux,
can you try to make new dvb-c network in TVH, with manual added mux,

and attach to Panasonics sat>ip server, to see if it will work?

----

some side information
https://trac.videolan.org/vlc/ticket/16587 http://www.hifi-forum.de/viewthread-315-85.html not for maloumnici

Anonymous

saen acro wrote:
> user#26890 now when you have correct freq/SR/Qam on working mux,
> can you try to make new dvb-c network in TVH, with manual added mux,

> and attach to Panasonics sat>ip server, to see if it will work?

Baby - this has already been done. (information processing....)

> ----
>
> some side information
> https://trac.videolan.org/vlc/ticket/16587 > http://www.hifi-forum.de/viewthread-315-85.html

> not for maloumnici

5 years old - fixed by JB imself.

Anonymous

Sven Rueberg wrote:

> I installed the DVBViewer Pro Demo. It found my TV>IP server and - after a full DVB-C scan - all channels of my local cable provider. I can now play all the (uncrypted) channels, e.g. Das Erste HD. Also, all the information that one need to manually create a rtsp request (in particular the PIDs) is there, see screenshot.

Great - but I wouldnow not invest time for creating rtsp requests. The idea was to access the SAT/IP server with rtsp to

make sure that it works.

Done. SAT-IP Server works and is accessible. AND: there was no magical config option needed to get it up'n'running :)=)

BTW: do you see all tuners within DVB Viewer ? (I remember that under tvh there was only one tuner).

> OK, that shows me that, in principal, the Panasonic TV>IP server is working. VLC might not be able to play the streams due to the (faulty/non-standard?) m3u playlist provided by the Panasonic TV>IP server. This playlist lacks symbol rate and PID information. With DVBViewer Pro Demo having found all my channels, to my understanding, I should be able to export DVBViewer's channel list in m3u format and use it for VLC.

Hmmm - I don't know if a export of m3u from dvbViewer works.

Besides: with tvh in front of the SAT-IP you dont't need the (idiotic) m3u list handling. For every oekosystem

there is a good tvh client (kodi / ios / libre ). It is also possible to start vlc directly from the tvh gui.

(Besides: this setup is the only solution if you want centralized decryption for all clients :)

Anonymous

Flole Systems wrote:

> There are many different options in Tvheadend, if it's not set properly it won't work. You need to figure out the right options (or at least what is different between the Tvheadend and DVB Viewer requests).

I doubt that it makes sense to look into the differences between tvh and DVBV in this setup. Even if there are findings they would never be fixed within tvh, because there is no support or bugfixing for tvh 4.2 anymore.

Right: It is usually the best choice to leave all options in the default state. It is usually timewasting ghosthunting to hope for "the unicorn option" which solves all problems, e.g. RTP supported.

Unfortunatly I'm not sure what is included in the tvh version above (Tvheadend 4.2.8-34). So it is impossible to decide if tvh 4.2.8-34 should work or if it can't work. This version should have SAT-IP support: but there is no stable release afterwards.

But I'm sure:

if DVBViewer Pro works than tvh 4.3-1886~g51a4c5bec works out-of-the-box. The tuners can be

scanned and are managed by tvh: there is no need to set another magical option.

Flole

Some Servers need specinv set for example, not specifying it or specifying it incorrectly causes the exact issues you are describing.

Anyways, using old versions like 4.2 is almost never a good idea, so update to latest first.

SvenR

In both DVB Viewer and Tvheadend, I only seeone DBV-C tuner - but I think that this is ok since I enable only the DBV-C section of my TV to be used with the TV>IP server.

!Screenshot1.jpg!

What I now did (to the best of my knowledge):
* Step 1: I did a fresh re-install of Tvheadend.
* Step 2: Tvheadend found the Panasonic TV>IP server at its IP and displayed it as a folder under "TV adapters". However, it did not display a concrete tuner under this folder when "Tuner configuration" was set to "auto". I manually changed this option as to "DVBC-1", and my DVC-C tuner popped up. Additionally, I actived "RTP/AVP/TCP (embedded data)". The other options in this sections were left untouched.
!screenshot2.png!
* Step 3: In the tuner parameters, I enabled the tuner and connected the network (I did that in the next step and came back to connect the network...). I set "network type" to "DVB-C" but Tvheadend seems to frequently forget this setting or does not correctly display. I left the "UDP RTP port number" to zero while I assume that Tvheadend will use default values then. (If I would need to set this, I could set this to 554 since I now that my TV is listening on this port.)
!screenshot3.png!
* Step 4: I created a network named "Kabel Baumann" and attached it to the tuner (see step #3). I left "SAT>IP source number" to be zero. I guess that this is ok.
!screenshot4.png!
* Step 4: I manually created a mux at frequency 122 MHz, symbol rate 6900 kSym/s, QAM256. This should be a valid mux confirmed by both the channel list of my tv cable provider and by the channels found by DVB Viewer Pro.
!screenshot5.png!
* Step 5: I then enforced a scan in the "networks" section of Tvheadend.
* The result is that Tvheadend keeps stumbling over this "RTSP error -5 (input/output error)".


2021-07-03 13:47:10.370 mpegts: 122MHz in Kabel Baumann - tuning on SAT>IP DVB-C Tuner #1 (192.168.1.12)
2021-07-03 13:47:10.370 epggrab: 122MHz in Kabel Baumann - registering mux for OTA EPG
2021-07-03 13:47:10.371 subscription: 0001: "scan" subscribing to mux "122MHz", weight: 5, adapter: "SAT>IP DVB-C Tuner #1 (192.168.1.12)", network: "Kabel Baumann", service: "Raw PID Subscription"
2021-07-03 13:47:10.374 satip: SAT>IP DVB-C Tuner #1 (192.168.1.12) - RTSP error -5 (Eingabe-/Ausgabefehler) [6-0]
2021-07-03 13:47:15.370 mpegts: 122MHz in Kabel Baumann - scan no data, failed
2021-07-03 13:47:15.370 subscription: 0001: "scan" unsubscribing
2021-07-03 14:04:00.982 mpegts: 122MHz in Kabel Baumann - tuning on SAT>IP DVB-C Tuner #1 (192.168.1.12)
2021-07-03 14:04:00.983 subscription: 0002: "epggrab" subscribing to mux "122MHz", weight: 4, adapter: "SAT>IP DVB-C Tuner #1 (192.168.1.12)", network: "Kabel Baumann", service: "Raw PID Subscription"
2021-07-03 14:04:00.986 satip: SAT>IP DVB-C Tuner #1 (192.168.1.12) - RTSP error -5 (Eingabe-/Ausgabefehler) [6-0]
2021-07-03 14:04:35.982 subscription: 0002: "epggrab" unsubscribing

I read in another forum that it might have to do with the port 554 used by my TV>IP server. Since Tvheadend is running as a normal user on my Pi, ports below 1000 cannot be accessed by Tvheadend. Maybe running Tvheadend as root could be a solution?

Flole

Use latest Tvheadend and not some old version and don't enable that RTP/AVP/TCP option, your server most likely doesn't support it and it won't work.

Anonymous

Flole Systems wrote:

> Some Servers need specinv set for example, not specifying it or specifying it incorrectly causes the exact issues you are describing.

We've done a clientside blackbox test. tvh doesn't act as SAT-IP server in this config. Your

statement would mean that tvh needs special settings ?

Or does only the old version needs special settings ?

Flole

Some servers require specinv to be passed (either on or off), others require it to not be passed (auto detect, default for Tvheadend). There are several servers in Tvheadend with "predefined settings" but not all servers are in there. So you might have to specify it.

All that can be found out when comparing the requests.

SvenR

Flole Systems wrote:

> Use latest Tvheadend and not some old version and don't enable that RTP/AVP/TCP option, your server most likely doesn't support it and it won't work.

Will do tomorrow and will come back then. Thanks!

Anonymous

Flole Systems wrote:

> Use latest Tvheadend and not some old version and don't enable that RTP/AVP/TCP option, your server most likely doesn't support it and it won't work.

Hmm, it does work without any problems with version tvh 4.3-1886~g51a4c5bec. Sure : this option is sufficient but not necessary.

The latest version of tvh will only work in this setup if the SAT-IP server supports "Interlaved TCP transfer mode" ? So tvh will suport only SAT-IP servers which provide this feature?

Surprise, surprise. Sounds like there will be more issues after update to latest master.

Flole

What are you talking about? Why would the latest version only work if it supports that? Just because an option is there it doesn't mean you need to enable it.

You're trying to come up with weird scenarios (that mostly consist of incorrect settings) right now and then complain about issues. Obviously if you specify wrong settings for the server you're trying to connect to it won't work, that shouldn't be surprising at all. Also if you don't have the "disable firmware/device specific workarounds" option set part of your settings could be overridden automatically, then you can specify whatever your want and that option fixes those.

SvenR

I was too curious and opened my notebook again... I discoverd that when Idisabled the "RTP/AVP/TCP (embedded data)" setting in the "TV adapters" section, Tvheadend was able to scan the manually created mux and does find the services in the mux. I can manually create a channel from one of the services and press "play this stream" in the "channels" section. VLC then opens and plays the channel.

I would say that - taking into consideration the original topic of the thread - the issue has been solved and my Tvheadend installation now works. I have to confess that I have kept my fingers off that "RTP/AVP/TCP (embedded data)" setting in the first place ... Thanks and sorry to all of you! ;)

One follow-up question on this:
* Since I unfortunately cannot use one of the list of pre-defined muxes: Do I need to create all muxes manually now?

Flole

You should be able to delete all muxes, force a scab and then the NIT automatically tells Tvheadend which other muxes are available (if you have detection for new muxes enabled).

Anonymous

Flole Systems wrote:

> What are you talking about? Why would the latest version only work if it supports that? Just because an option is there it doesn't mean you need to enable it.

Hä ? You wrote: "Use latest Tvheadend and not some old version and don't enable that RTP/AVP/TCP option, your server most likely doesn't support it and it won't work."

O.K: so I use the latest tvh ; and I will not enable THE Option then your guess is: the SAT-IP Server does not support it and it will not work.

Or stripped down: don't enable the option and it won't work. Tertium non datur: it will only work if the option is set.

Or did you forget a "because" ?

> You're trying to come up with weird scenarios (that mostly consist of incorrect settings) right now and then complain about issues. Obviously if you specify wrong settings for the server you're trying to connect to it won't work, that shouldn't be surprising at all.

Wired szenarios ? tvh in front of an SAT-IP server is a weired szenario ? I don't think so. It's natural that in the first try a SAT-IP Server is not configured proberly. So it is straightforward to check that it responds as expected.

Instead it turns out that tvh 4.2.8 seems to work out-of-the-box if the SAT-IP Server is reachable. No need for special or magical setings. Or short: if Saen had shut up, then threadstarter would not focus on this option and there would be no problem at all.

> Also if you don't have the "disable firmware/device specific workarounds" option set part of your settings could be overridden automatically, then you can specify whatever your want and that option fixes those.

There is no documentation for this option at all - so I cannot comment on this point.

Flole

No, your understanding is not correct: The server doesn't support it and it won't work (because the server doesn't support it). Not sure how you read anything about latest master not working or whatever.

Anonymous

Flole Systems wrote:

> No, your understanding is not correct: The server doesn't support it and it won't work (because the server doesn't support it). Not sure how you read anything about latest master not working or whatever

Understood that my understanding is not correct. And in this sentence there is the "because".

Anonymous

Sven Rueberg wrote:

> the issue has been solved and my Tvheadend installation now works.

Great. Now the encrypted channels.

Anonymous

Flole Systems wrote:

> Some servers require specinv to be passed (either on or off), others require it to not be passed (auto detect, default for Tvheadend). There are several servers in Tvheadend with "predefined settings" but not all servers are in there. So you might have to specify it.

WEBUI Doc is concerning this point completly empty. Is there an overview which Servers under which
version are supported or not ? It would be nice to know forwhich severs a user has to specify more
detailed.

> All that can be found out when comparing the requests.

For a typical tvh user: completly unrealistic.

Flole

That should be mentioned in the servers documentation what it expects. It is not the job of the client to document what each and every server needs.

If you want to improve the docs I am waiting for your PR.

I don't really care if it is unrealistic for a typical user, in the end Tvheadend is free software that's maintained on a voluntary basis, so if someone expects something that just works or any kind of support then commercial software, possibly even with a service level agreement or some kind of support contract, is the better choice. However, people who want to spend time to investigate issues and want to find the cause of the issue and a fix will get advice here.

« Previous Page Next Page »