23 replies to this topic

[stick50jr]

I tried to display a transcoded remote channel from Duo2 to Duo2

#SERVICE 1:0:1:250:251:1010:EEEE0000:0:0:0:http%3A//192.168.178.35%3A8002/1%3A0%3A1%3A250%3A251%3A1010%3AEEEE0000%3A0%3A0%3A0:ABC News 24

It failed with "Timeout reading PAT".  Non-transcoded remote channel works correctly (from port 8001 duo2 to duo2) but the internet bandwidth is not sufficient.  The transcoded stream (from port 8002) works well to my PC with VLC over the same internet link.

 

I read somewhere on this forum that the ET10000 has the same problem and that it is caused by the driver implementation failing to repeat the PAT/PMT information regularly within the transcoded stream. 

Apparently VLC doesn't care, but enigma2 cannot cope without the repitition.

 

Is my understanding correct, and is it possible to fix without Vu+ changing their drivers?

[stick50jr]

This is where I read about the same problem::

 

http://forums.openpl...er-enigma2-box/

 

There hasn't been any resolution / update to this thread for a while.

Edited by stick50jr, 7 April 2016 - 08:36.

[WanWizard]

If that is the problem, then it must be fixed in the drivers.

 

But I haven't seen a driver update for the ET10000 in over a year, and transcoding from the 10K to another box works fine, it is how I watch TV when I'm on the road (using a VU+ Zero with OpenVPN and fallback tuner config to connect to my 10K at home).

[stick50jr]

Thanks Wanwizard,  Seems like the 10K is okay but the Duo2 remains with this problem.

[WanWizard]

I'll try to run some tests with my Duo2 later.

[Erik Slagter]

Both the ET10000 and the Duo2 have had fixes for this problem and both them have been tested by me.

[WanWizard]

Ok. That saves me having to test it

[stick50jr]

Both the ET10000 and the Duo2 have had fixes for this problem and both them have been tested by me.

 

Okay Erik, I understand that you believe this has been fixed.  If so, I'm not sure what my problem is

 

Thanks for your replies...

Edited by stick50jr, 8 April 2016 - 13:57.

[athoik]

Can you give a try with 4114 service ref?

#SERVICE 4114:0:1:250:251:1010:EEEE0000:0:0:0:http%3A//192.168.178.35%3A8002/1%3A0%3A1%3A250%3A251%3A1010%3AEEEE0000%3A0%3A0%3A0:ABC News 24

[stick50jr]

Can you give a try with 4114 service ref?
 

#SERVICE 4114:0:1:250:251:1010:EEEE0000:0:0:0:http%3A//192.168.178.35%3A8002/1%3A0%3A1%3A250%3A251%3A1010%3AEEEE0000%3A0%3A0%3A0:ABC News 24

I tried your suggestion... but this entry shows as <n/a> in the channel list and when I change to this <n/a> channel, I just get a blank screen (but no 'Timeout reading PAT').

[stick50jr]

What is the '4114' supposed to be?

[Trial]

Hi,

perhaps 4097 was meant.

 

ciao

[athoik]

another way to read ts streams.

[stick50jr]

Hi,

perhaps 4097 was meant.

 

ciao

Thanks, '4097' works.

 

With '4097', the channel list identifies the channel name and picon and after a bit of buffering, it plays the transcoded stream.

 

Many thanks to all who have helped me.

Edited by stick50jr, 9 April 2016 - 10:07.

[stick50jr]

Well I found a post from Wanwizard that explains how 4097 is different from 1

 

http://forums.openpl...ndpost&p=519202

 

 

1: means that the stream is processed by the hardware. 4097: means that the stream is processed by gstreamer, before it goes into the hardware decoder.

 

The first will only work for MPEG-TS streams, and must in fact only be used for "internal" channels, not for streams, because there is not buffered, and there is a DVB compliant expected stream. That black image is probably because the decoder must wait for a complete frame.

 

So it seems that the Vu+ hardware was not the issue.  I guess it would be better if the transcoded stream produced by Duo2 was a fully compliant DVB stream... maybe then it would play without having to be put through gsteamer.

 

Thanks again all.

Edited by stick50jr, 9 April 2016 - 12:05.

[WanWizard]

Technically, a stream can be an MPEG-TS stream too, and the transcoding stream is one.

 

The problem here is that the hardware expects the TS to be in a specific DVB compliant format, and VU+ haven't bothered, probably assuming that transcoded streams will always be played by software (gstreamer, vlc, a mobile app, etc).

 

By changing the 1 to a 4097, you change the path of the stream from going directly into the hardware to going through gstreamer, working around the bug. That works for single streams you manually add to your bouquet, but it won't help you if you want to use the fallback tuner.

[stick50jr]

Technically, a stream can be an MPEG-TS stream too, and the transcoding stream is one.

 

The problem here is that the hardware expects the TS to be in a specific DVB compliant format, and VU+ haven't bothered, probably assuming that transcoded streams will always be played by software (gstreamer, vlc, a mobile app, etc).

 

By changing the 1 to a 4097, you change the path of the stream from going directly into the hardware to going through gstreamer, working around the bug. That works for single streams you manually add to your bouquet, but it won't help you if you want to use the fallback tuner.

 

I agree, it is a Vu+ bug.  I have made a bug report to Vu+... maybe they'll surprise me with a fix

 

I assume fallback tuner will work with non-transcoded streams on the Duo2... so use is limited to LAN (not WAN).

 

Thanks again for your interest.

Edited by stick50jr, 9 April 2016 - 12:41.

[WanWizard]

For the VU+, yes. The fallback tuner works fine with the transcoded streams from the ET10000 or the Mutant HD2400.

[stick50jr]

"Such is Life"  with Vu+

[Erik Slagter]

The problem was only the PAT and the PMT not being repeated, it was only sent once. Which in itself isn't a crime, but it's better to repeat them. In this case enigma relies on the tables being repeated every once in a while. All of VU+, Mut@ant and Xtrend have patched their drivers so the tables get repeated and it works, tested it.