[solved] Possible (TsReader?) regression in 1.16 (1 Viewer)

[Threarah]

I just had a brief try seeking a couple of dozen times with a 15min buffer on live TV without any apparent problems (MP 1.16 + default 1.16 TsReader). I'll leave the buffer to grow to an hour or so and will try again then, but at this stage I've only seen it happen on recordings.

*edit* I let the live TV buffer grow some more and was unable to freeze the image by seeking. I gave it a good 30-40 seeks without any problem. I then tried playing a recording and the image froze on the second seek. So at this stage it appears that seeking through a live TV buffer is fine, though seeking through a previous recording causes issues.

 

[Sebastiii]

Could be nice to have a new set of logs

 

[HTPCSourcer]

So at this stage it appears that seeking through a live TV buffer is fine, though seeking through a previous recording causes issues.

This is exactly what I had experienced for MP 2.1 and reported in our internal section. However, I don't recall having had the same trouble with MP 1.16. What I then found out is that the observed phenomenon seems to also be dependent on the codec used. Under 1.16 I was using MS-DTV but changed this to LAV with MP 2.1. I would need to reread my own TV issue thread, but if I remember correctly, these seek issues can be eliminated if I switch back to MS-DTV - unfortunately this brings other troubles because the channel swith times suddenly increase significantly.

@Threarah , you haven't added hardware info to your profile yet. What codec are you using and have you tried switching them to test if you can confirm this behavior for any codec?

 

[Threarah]

This is exactly what I had experienced for MP 2.1 and reported in our internal section. However, I don't recall having had the same trouble with MP 1.16. What I then found out is that the observed phenomenon seems to also be dependent on the codec used. Under 1.16 I was using MS-DTV but changed this to LAV with MP 2.1. I would need to reread my own TV issue thread, but if I remember correctly, these seek issues can be eliminated if I switch back to MS-DTV - unfortunately this brings other troubles because the channel swith times suddenly increase significantly.

@Threarah , you haven't added hardware info to your profile yet. What codec are you using and have you tried switching them to test if you can confirm this behavior for any codec?

I've added some basic hardware info to my profile now.

It's set to use LAV. I just tried changing to MS-DTV and found that the picture still freezes when seeking.

I've also just tested it on my laptop (MP 1.16 client only install) with the same results - seeking with the 1.16 TsReader will often make the picture freeze, whereas it works as expected with the more recent TsReader.ax posted above. The laptop is also set to use LAV, as MS-DTV just gives a black screen.

Could be nice to have a new set of logs

Want me to do anything in particular for the logs? Live TV? Recorded TV? Which version of TsReader.ax? Or just anything and everything?

*edit* Attached 2 sets of logs:

1.7z
MP 1.16 + default 1.16 TsReader
Played recorded TV
Seeked back and forth several times with image freezing

2.7z
MP 1.16 + dev TsReader build
Played recorded TV
Seeked back and forth several times without problem

 

[mm1352000]

@Threarah
I see you're using the MediaPortal Audio Renderer for TV. That's a potential source of problems.

Please can you try the 1.16 default TsReader with a DirectSound audio renderer?

Also, does the problem happen when seeking on a single-seat (ie. MP and TV Server on the same PC) installation?

 

[Threarah]

I just tried with a DirectSound audio renderer with no difference - the picture still froze with the default 1.16 TsReader.

And yeah, it does happen on a single-seat install too. 99% of the time I only ever use MediaPortal in a single-seat setup, but I thought I'd try it out on my laptop just to see if it was still an issue with different hardware/etc. Also, if its important, those 2 logs I attached above were done on my laptop as the HTPC/TV was in use at the time.

I think the important thing (apart from it being seemingly fixed in the later TsReader build) might be that it doesn't happen on every channel - and the channel it does happen on has had a very similar issue in the past.

 

[Owlsroost]

Thanks for the logs and testing.

I can confirm that the broadcast stream is still as oddball as it was 4 years ago (with about a 3 second time skew between the video and audio, for no good purpose that I can think of).

The logs/behaviour with the stock MP 1.16 TsReader version and the dev version look pretty similar, so I haven't worked out yet why the dev version is behaving better (but I haven't had the time to investigate it 'in depth' yet).

 

[1gkar]

Have just found this thread, as I have had the same issue. You appear to have everything under control. If you need extra logs, with different hardware, just let me know, Thanks to all who are attempting to fix this issue; & to Threarah for bringing this issue to the MP devs' attention.

 

[Owlsroost]

If you need extra logs, with different hardware, just let me know,

Yes please (with the standard MP 1.16 TsReader.ax).

Also can you please try the dev TsReader attached here - Possible (TsReader?) regression in 1.16 - to check if that fixes the problem.

 

[ge2301]

I will test this, probably tomorrow.

Did you already run a test with MP2.1 to check if the freezes are gone?