Request for supporting Ceton devices on Linux

[mvallevand]

PM me ssh or TeamViewer info and I will have look.

Martin

[run088]

end result

[mvallevand]

Thanks for sharing that I assume things are good now. Also thanks for the time today today, sorry it took so long to understand you edited opendct.sh but it was good for me to see the Cetons in action.

To recap the last few days

- there was a bug in opendct.py creating the Linux extra
- time.sleep is not needed but increasing the timeout does hurt.
- do not edit opendct.sh
- if you use python to test tuning reception and not opendctsh you will need to restart the service (I forgot to mention this)

We also found out that the Ceton creates ts files that sub's default transcoding does not like so the web server won't play it. ffplay should always be the first tool used for testing before going to NextPVR . Using Dynamic mode in opendct is recommended for browser testing and most client. Some clients will be able to use raw mode but many will not. Even Kodi on different platforms has trouble. YMMV.

If your goal is to use Plex, it is supposed to use smart ffmpeg processing so in theory it should be able to deal with the raw files, but it might not be as smart as full demuxer. If you do use raw mode remuxing in post processing makes sense anytime

Thanks again for the time. Not sure if there are other Ceton Linux users out there but I will clean up opendct.py and little more and add it to a general post for Linux and Window users.

Martin

[sub]

We also found out that the Ceton creates ts files that sub's default transcoding does not like so the web server won't play it.

Have you got a sample file so I can see what the problem is?

From memory, when v4 supported the Ceton devices natively, the transport stream arrived with the PAT/PMT listing multiple channels, but only a single one had data. (ie, they'd just filtered the stream to drop the PIDs they weren't interested in, but didn't rewrite the PAT to only include the single channel). Other devices output TS streams that only have a PAT listing a single channel. NextPVR v4 had to rewrite the PAT output by this device, before it was written to disk to make it more standard.

[mvallevand]

I can send it a small one if you want, but the issue is as you describe it. An unfiltered PAT with the filtered a/v streams for the program. That is why the opendct option to use ffmpeg to rewrite in on the fly works and I recommend it now seeing the data.

The issue with the web browser is the map commands since they ignore the program number. A generic ffmpeg -i filename -codec copy -c copy works better since it rewrites PAT properly. I think the player is the issue though since the data does grow without stopping.

Martin

[sub]

I can send it a small one if you want, but the issue is as you describe it. An unfiltered PAT with the filtered a/v streams for the program. That is why the opendct option to use ffmpeg to rewrite in on the fly works and I recommend it now seeing the data.

Yeah, you pretty much need to do something like this before feeding the data to NextPVR. v4 did the same thing in the past, to rewrite the PAT as the data was received, before it was passed on to other components.

[run088]

Its all bad. I can't for the life of me figure out what exactly is the problem.

I added a second ceton card to my machine. When I installed it the old tuner was still working.

After I had its networking configured I went back into nextpvr settings and deleted the tuners. I then reran the INSTALL Ceton command to get the new tuners to show up. Now opendct gets no connection with nextpvr when I send channel commands.

Any help would be greatly appreciated.

[mvallevand]

After this many posts you should know that posting without logs is a waste of time.

Martin

[run088]

here you go

[mvallevand]

The NextPVR log doesn't show you trying Live TV after the logs for the OpenDCT restart, perhaps you are testing wrong again. When you send NextPVR logs don't just copy the logs use the web server download to flush them first.

Martin