TV Server Crashes After Recording Ends (1 Viewer)

[georgius]

@Sigpi007 , another special build for you. It should be better, I implemented for your server ignoring of errors.

...maybe it is the cause why playback stops.

If the problem is a client playback issue, yes - possibly.

Because filter close and re-open connection and continue delivering data, the playback on client should continue. I tested such situation, but I'm using LAV filters.

...but from the reconnecting and other messages on the server side, it seemed like the problem was more likely to be server side. Also, I thought Sigpi007 said that the problem didn't happen with the other IPTV/splitter filters.

Yes, remote server sends totally wrong data. On data track could be only valid RTP packets, but in that case arrived pure text. Possibly other implementations just ignore such data, but I'm not sure, what is in this case right approach.

 

[Sigpi007]

is there any reason why are you using 'Microsoft DTV-DVD Video Decoder' instead of recommended LAV filters?

I didn't realize that I was. I mean... I didn't change off of the LAV filters. I did as little changes to the default installation/configuration process as possible. I even checked my settings and everything is set to LAV. See attached photos. Maybe I forgot something?[DOUBLEPOST=1417215745][/DOUBLEPOST]@georgius

I tried the new files but no DUMP file was created after testing and successfully seeing another playback freeze.

 

[georgius]

I didn't realize that I was. I mean... I didn't change off of the LAV filters. I did as little changes to the default installation/configuration process as possible. I even checked my settings and everything is set to LAV. See attached photos. Maybe I forgot something?[DOUBLEPOST=1417215745][/DOUBLEPOST]@georgius

I tried the new files but no DUMP file was created after testing and successfully seeing another playback freeze.

Settings seems to be correct. Attach latest freeze logs. Going to sleep, too tired for today.

 

[Sigpi007]

logs attached...

 

[georgius]

logs attached...

Try attached filter version.

EDIT: For sure also attach logs.

 

[georgius]

@Sigpi007, I hope that you click OK button in MediaPortal Configuration. If not, run MediaPortal Configuration tool, go to TV codec settings, check if there are set LAV filters (except Audio renderer) and press OK. Then attach MediaPortal.xml file from C:\ProgramData\Team MediaPortal\MediaPortal folder. In your current configuration file are not set LAV filters for TV, so another filters are used.

 

[Sigpi007]

@georgius and @mm1352000

Georgius... something worked. After messing with the LAV filters and applying the Filter_libceton_V02 files I no longer get freezes. I tested on a few different channels watching TV up to 5 minutes before I changed channels. Unfortunately I didn't expect this to happen, so I applied both things before testing, so I don't know which one did the trick. Here's a few additional notes...

LAV Filters:
I opened the MP Client config and went to TV codecs, then selected anything BUT the LAV filters... hit "OK" to close MP config... then reopened it and switched all back to LAV filters and hit "OK" just to be sure that the program would recognize the update. Then when watching TV, I pressed Shift+1 to see the graph which confirmed that playback was now using the LAV filters. I'm attaching the Mediaportal.xml file below which should reflect those changes.

New filter vs older versions... let me know if you want me to go back and test Filter_libceton_V01 now that we have LAV filters confirmed working. This could isolate which change fixed the playback freeze issue.

-sp[DOUBLEPOST=1417285422][/DOUBLEPOST]UPDATE: I reapplied Filter_libceton_V01 and started Playback of TV... and did Shift+1 to confirm LAV filters being used. The playback froze around 30 seconds into the program again... so this should isolate the fix to something you did between V01 and V02. (Good stuff!)

More logs from this test. I did not clear out the previous logs this time. This test was run around 12:20 for reference.[DOUBLEPOST=1417285602][/DOUBLEPOST]And since this forum is merging posts...

the log files with the suffix _29_11_14_12_00.zip are associated with Filter_libceton_V02

the log files with the suffix _29_11_14_12_22.zip are associated with my retest of Filter_libceton_V01

 

[georgius]

It seems that there is still some bug in RTSP protocol. The stream should be reopened immediatelly after error, but in this case it takes much longer time. I need to investigate this.

 

[georgius]

It's feature, not bug. But it's little bit complicated. Filter sends OPTIONS or GET_PARAMETER request to remote server in regular intervals (half of timeout specified by server (default timeout value is 60 seconds, so each 30 seconds is sent request)). Each request has its own timeout (default is 20 seconds). And now what happend: filter sent OPTIONS request with timeout 20 seconds at 29-11-2014 12:19:21.994 (so timeout will occure at 29-11-2014 12:19:41.994). Problem with received text "i'm not dead yet" occured at 29-11-2014 12:19:25.098. So, filter need to wait at least 16.896 seconds to issue new request. At 2014-11-29 12:19:38,673 was pressed stop in MP - 3.321 seconds before filter OPTIONS request timeout. After that filter closed and opened new connection, but in that time it was irrelevant.

It will be great when specifying filter RTSP url is url created with reasonable parameters, especially for timeouts - as I saw in logs, 500 ms is sufficient value. This is also little bit complicated, because we have standard MP IPTV filter and this new one. In theory is also possible to separate filter IPTV and OnlineVideos settings, but I don't have any idea about reasonable values (except of UDP protocol, which I'm using).

 

[Sigpi007]

Nice! Sounds like you figured out a bunch of stuff. What can I do to help with next steps?