Tvheadend

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.

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 ?

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.

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!

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.

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.

I was too curious and opened my notebook again... I discoverd that when I disabled 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!

• Since I unfortunately cannot use one of the list of pre-defined muxes: Do I need to create all muxes manually now?

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).

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.

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.

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".

Sven Rueberg wrote:

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

Great. Now the encrypted channels.

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 for which 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.

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.

I have now mapped the services to channels. Everything works fine so far: I can watch uncrytped TV channels on my iPad using TvhClient. Great!

Der Depp vom Dienst wrote:

Great. Now the encrypted channels.

I have a CI+ module with a valid smartcard inserted in the CI slot of my Panasonic TV. Is there a way to descramble the encrypted German HD+ channels when streamed through Tvheadend?

Flole Systems wrote:

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.

Inkonsistent. Thats a good attitude, but then the implementation of some specials
handlings destroys this.

Right: The Client should only document its own behaviour. So it would be nice if client user would know
for which server the client uses "predefined settings".

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

Deadlock. Is there an overview which Servers under which
version are supported or not ?

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.

Hmmm - for threadstarter version 4.2 just works. The problem was the "advice" which was given here. Once again a great saen advice: destroys the connection. "update to latest master": not neccessary.

"I don't really care if it is unrealistic for a typical user,". Thats an adequate attitude as main developer. So any improvements are superfluous. Good to know.

@ Flole Systems
in
https://github.com/tvheadend/tvheadend/blob/2c0d0a52d516efc9100d1ef110f11b737892c1c3/src/input/mpegts/satip/satip.c
there is a section
satip_device_hack
with solve some devices bugs
Panasonic missing there

saen acro wrote:

@ Flole Systems
in
https://github.com/tvheadend/tvheadend/blob/2c0d0a52d516efc9100d1ef110f11b737892c1c3/src/input/mpegts/satip/satip.c
there is a section
satip_device_hack
with solve some devices bugs
Panasonic missing there

Oh Baby: there is no "hack" needed for Panasonic.

The complete thread was only about this issue - and you missed it.

Der Depp vom Dienst wrote:

Deadlock. Is there an overview which Servers under which
version are supported or not ?

All servers fulfilling the SAT>IP Specification are supported.

So any improvements are superfluous. Good to know.

No, PRs are always welcome (and also new developers).

Der Depp vom Dienst wrote:

Oh Baby:

Please refrain from calling other users "baby" or other inappropriate names.

Sven Rueberg wrote:

I have now mapped the services to channels. Everything works fine so far: I can watch uncrytped TV channels on my iPad using TvhClient. Great!

Der Depp vom Dienst wrote:

Great. Now the encrypted channels.

I have a CI+ module with a valid smartcard inserted in the CI slot of my Panasonic TV. Is there a way to descramble the encrypted German HD+ channels when streamed through Tvheadend?

I just want to briefly come back to this issue after I did some research on this myself. It is my understanding that in any case the CI+ module needs to be physically connected to the computer running Tvheadend, e.g. through an easymouse module. There is no way to make Tvheadend descramble channels while the smardcard resides in the CI+ slot of the TV. Correct?

Sven Rueberg wrote:

I just want to briefly come back to this issue after I did some research on this myself. It is my understanding that in any case the CI+ module needs to be physically connected to the computer running Tvheadend, e.g. through an easymouse module. There is no way to make Tvheadend descramble channels while the smardcard resides in the CI+ slot of the TV. Correct?

Include some real-world tests in your research.
Discoveries are not made on paper.

Flole Systems wrote:

Der Depp vom Dienst wrote:

Oh Baby:

Please refrain from calling other users "baby" or other inappropriate names.

Nonsens. "Baby" means nothing more or less than "childish adult person".

Why is this a problem - when "idiot" or "Spammer" is not a problem ?

BTW: don't abuse this thread for personal discussions.

Sven Rueberg wrote:

I just want to briefly come back to this issue after I did some research on this myself. It is my understanding that in any case the CI+ module needs to be physically connected to the computer running Tvheadend, e.g. through an easymouse module.

If "physically connected" means "by network / by usb / ": yes.

There is no way to make Tvheadend descramble channels while the smardcard resides in the CI+ slot of the TV. Correct?

Correct.

saen acro wrote:

Include some real-world tests in your research.
Discoveries are not made on paper.

Nonsens.

Way to go is:

1) TVH cannot use german CI+ module without errors. The implementation is buggy and will not work. So don't waste your time trying.

2) use the canonical solution:

- hide any source (DVB-C / SAT/IP / DVB-S) behind one tvh instance (done)
 - check if your card is supported 
 - activate and configure the easymouse solution
   (first problem is usually FTDI support for the usb device. so check for these two lines:
          usb 4-5: Detected FT232RL
          usb 4-5: FTDI USB Serial Device converter now attached to ttyUSB0 

- connect to tvh via newcamd or dvbapi

I don't know if this funktion (CA) is already available with 4.2.8.

Der Depp vom Dienst wrote:

Nonsens.

Way to go is:

1) TVH cannot use german CI+ module without errors. The implementation is buggy and will not work. So don't waste your time trying.

2) use the canonical solution:

- hide any source (DVB-C / SAT/IP / DVB-S) behind one tvh instance (done)
- check if your card is supported
- activate and configure the easymouse solution
(first problem is usually FTDI support for the usb device. so check for these two lines:
usb 4-5: Detected FT232RL
usb 4-5: FTDI USB Serial Device converter now attached to ttyUSB0

- connect to tvh via newcamd or dvbapi

I don't know if this funktion (CA) is already available with 4.2.8.

What stupid explanation to use software cam emulator.
Even explanation is not full, not sayng that FTDI support is in kernel.
This stupid advice will not work when operator implement cardless cam, as some operators already do.

Der Depp vom Dienst wrote:

Flole Systems wrote:

Der Depp vom Dienst wrote:

Oh Baby:

Please refrain from calling other users "baby" or other inappropriate names.

Nonsens. "Baby" means nothing more or less than "childish adult person".

Why is this a problem - when "idiot" or "Spammer" is not a problem ?

Knowledge for grandpas

reality hurts