Transcoding LiveTV

[sub]

Could there be a collision on transcode.txt?

Yep, could be. I've changed this for the next release.

[madas]

Thanks sub - whats the next release due?

[sub]

Probably about 3 weeks away.

[uspino]

So here's my strange scenario. I stream live TV from NextPVR to different apps. The new Apple TV is actually perfect for that: you can turn your NextPVR server into a Slingbox and watch live TV through apps like iPlayTV, MRMC, etc. I have an m3u list whith all the channels I use, in the form of http://IP:PORT/transcode?channel=600&res...rate=2000k

It works great, and I've set up config.xml so ffmpeg uses Intel QSV encoder, which hardly uses any CPU on the server.

But here's what happens. Every time I start streaming, NextPVR starts ffmpeg encoding, creates a new ts file on the buffer directory and a (mp4) ts file on the Recording directory, BUT exactly 6 seconds later terminates those files and creates another ts and and another (mp4) ts file, and only then the streaming video shows up on the client. When you stop, both ts files and both (mp4) ts files are there, perfectly transcoded (and never automatically deleted on the recording directory, by the way). Also, the server takes a long time (around 15 seconds) to close ffmpeg once the client has stopped streaming. Can anybody help with all this? Here are the logs (first ffmpeg log, second ffmpeg log and NPVR log) from one short streaming session. Thanks!

[mvallevand]

It makes no sense why you didn't open a new thread. In any case NextPVR web server is expecting only only http call to start streaming your client is making multiple probes to identify the stream characteristics. Adding a client identifier to the url might speed up the close time.

NextPVR also doesn't really now you have finished streaming for 10 seconds and with the additionaly buffering of transcoding 15s sounds reasonable to me.

Martin

[uspino]

Thanks Martin, adding "&client=1" to the url solved the "double file" issue. The (mp4) ts file still doesn't get deleted; the file seems to stay locked by NPVR Recording Service, so only after a stop/start of the process it can be manually deleted. Any help with that?

You are right: I should have opened a new thread, but I thought most of the info regarding live tv streaming was in here.

Thanks!

[uspino]

Thanks Martin, adding "&client=1" to the url solved the "double file" issue. The (mp4) ts file still doesn't get deleted; the file seems to stay locked by NPVR Recording Service, so only after a stop/start of the process it can be manually deleted. Any help with that?

You are right: I should have opened a new thread, but I thought most of the info regarding live tv streaming was in here.

Thanks!

I spoke too soon. It looks like if I start streaming inside the LAN, only one file is created. If I call for a stream from outside the LAN, the ghost 6-seconds file is created, before the second one actually initiates the streaming. No difference with or without &client argument. Back to square one.

[sub]

I spoke too soon. It looks like if I start streaming inside the LAN, only one file is created. If I call for a stream from outside the LAN, the ghost 6-seconds file is created, before the second one actually initiates the streaming. No difference with or without &client argument. Back to square one.

You'd need to supply the logs showing the attempt for us to be able to tell you anything.

[uspino]

Here they are, including the two ffmpeg logs created (with "-report") by the two instances of ffmpeg that NextPVR triggers on any streaming attempt. The two ts files on the Buffer directory are subsequently deleted; the two (mp4) ts files on the Recording directory are not. Their names in this case (referenced in the logs) are: live-tCNNHD-8760-1.ts and live-tCNNHD-8760-5.ts.

Thanks!

[sub]

Those calls don't have the "&client=" parameter.