How to: use DD Octopus Net in MP (3 Viewers)

[FreakyJ]

It is definitive a MP related problem, I will have to take a look at the src, but that could take some time

 

[FreakyJ]

Bad news :/
Looks like this temporary workaround will only work without EPG.
The reason is that we insist that there is more on this url than actually is.
What does that mean:
- I have to talk to Jörg to remove the PIDs 16,17,18 again (but he is on vacation currently)
- we need Webgrab++ to get EPG

And I don't see any quick and easy way to fix this

 

[MightyDetail]

No problem (for me), just using TV Movie EPG. There are just a few channels not supported by TV Movie like ProSieben Fun.

 

[mm1352000]

Without code changes there is no way that I can see to properly optimise scanning.
You will have to scan once for each channel and be sure to include the following "global" PIDs: PAT, CAT, SDT, NIT and EIT. Required channel PIDs would be PMT, EMM, ECM, video PIDs, audio PIDs and subtitle PIDs. This scheme would not work for channels which change PIDs.
But you could remove the PID filter completely (pids=all).

 

[FreakyJ]

You will have to scan once for each channel and be sure to include the following "global" PIDs: PAT, CAT, SDT, NIT and EIT. Required channel PIDs would be PMT, EMM, ECM, video PIDs, audio PIDs and subtitle PIDs.

Thanks for the answer mm!
But I think the problem is something different, please correct me if I should be wrong.

To save bandwidth we only request the pids for one channel, but to get EPG we had to add the pids 16,17 and 18.
Now if we have a URL like:
zdf_neo
rtsp://192.168.178.44/?freq=394&msys=dvbc&sr=6900&mtype=256qam&pids=0,650,660,670,671,672,675,680,16,17,18
TvService finds around 10 new channels (because of the PMT) and adds these to the DB and all get the same url which can't work, because we get only the video and audio pids for zdf_neo.
Maybe another example:
scanning this url (zdf_neo) with channel movementdetection activated:
rtsp://192.168.178.44/?freq=394&msys=dvbc&sr=6900&mtype=256qam&pids=0,650,660,670,671,672,675,680,16,17,18
gives me:
zdf_neo
zdf
zdfInfo
All wil have the same url: rtsp://192.168.178.44/?freq=394&msys=dvbc&sr=6900&mtype=256qam&pids=0,650,660,670,671,672,675,680,16,17,18
This can't work...
Now TvService scans zdf_info and updates all channels with this url:
URL: rtsp://192.168.178.44/?freq=394&msys=dvbc&sr=6900&mtype=256qam&pids=0,600,610,620,621,622,625,630,16,17,18

and if you don't activate the channel movement detection it updates all the channels with the same url to the same name (because it only compares the url).
I also added an option to disable the channel update function, so it still adds all chanles, but doesn't update the channels. The result is that only the first scanned channel of a transponder is working (what isn't that surprising, but I wanted to try it )

But you could remove the PID filter completely (pids=all).

I think this could be a solution! So we would have a much higher bandwidth (~50Mbit/s) usage, but for a temporary solution this shouldn't be a problem
So we would have one url per transponder like it is in DVB-C.
The advantage would be much faster channel scans (compared to 3h).
I will try it this evening and report back here

 

[mm1352000]

To save bandwidth we only request the pids for one channel...

Yes. This is also the underlying cause of all the problems that you're seeing.

...but to get EPG we had to add the pids 16,17 and 18.

Yes and no. The SDT and NIT PIDs also help you to get full channel information (name, encrypted/free, number, type) in the scan.

Now if we have a URL like:
zdf_neo
rtsp://192.168.178.44/?freq=394&msys=dvbc&sr=6900&mtype=256qam&pids=0,650,660,670,671,672,675,680,16,17,18
TvService finds around 10 new channels (because of the PMT)...

I don't quite agree. To be clear, the fact that the channel is in the PAT and SDT means that it would be found even if the PMT PID is blocked. If you were to allow only the PAT and correct PMT PID then you would get one channel... but it would have no name and EPG might not work.

...and adds these to the DB and all get the same url which can't work, because we get only the video and audio pids for zdf_neo.

Yes, I agree.

Maybe another example...

Yes, I understand this example too.

But you could remove the PID filter completely (pids=all).

I think this could be a solution! So we would have a much higher bandwidth (~50Mbit/s) usage, but for a temporary solution this shouldn't be a problem
So we would have one url per transponder like it is in DVB-C.
The advantage would be much faster channel scans (compared to 3h).
I will try it this evening and report back here

Right now this is pretty much the only way that the ONet (or any other SAT/CABLE>IP tuner will work with TV Server without code changes. It is not ideal because streaming only two transponders may saturate a 100 Mb/s connection and you don't get proper signal strength/quality readings. The only other way I can think of which would allow PID filtering to be used is to import the channels directly to the database rather than scanning... but of course creating the initial channel list is very time consuming. My approach is not to claim that hardware is supported until it works properly and that is why I previously said the ONet is not yet supported...

 

[KayDiefenthal]

a=fmtp:33 ver=<major>.<minor>;src=<srcID>;tuner=<feID>,<level>,<lock>,<quality>,<frequency>,<pol
arisation>,<system>,<type>,<pilots>,<roll_off>,<symbol_rate>,<fec_inner>;pids=<pid0>,…,<pidn>

you can get Level Lock and Quality it is in the sdp if you send Describe

 

[mm1352000]

you can get Level Lock and Quality it is in the sdp

Yep, I'm aware of this.
The current RTSP filter doesn't know about this and so it doesn't pass the details through to the TV library. That is what I meant.

 

[KayDiefenthal]

ok if you that know, is all allright
and i has you missunderstood

 

[mm1352000]

ok if you that know, is all allright
and i has you missunderstood

No problem and thanks for the tip.