Sometimes no image rendered when playing video (5 Viewers)

[doskabouter]

Finally got around to this mystery:
I now have logging on all the _state changes of the tsreaderplayer (that is used when determining g_player.playing, which in turn controls the isplayingvideo property)
happy testing!

 

[CyberSimian]

I now have logging on all the _state changes of the tsreaderplayer (that is used when determining g_player.playing, which in turn controls the isplayingvideo property)

Thank you for the updated files. I will install them and see if I can reproduce the problem.

When using the previous versions, I noticed that I was experiencing "micro stuttering" when watching live TV or recorded TV/video. There was no noticeable interruption in the audio, but the video would freeze for a fraction of a second (guess: 0.2-0.3 seconds), and then jump to catch up with the audio. This happened frequently, but not with any regularity. Initially I thought that this was caused by the two USB disks that I had recently connected to the system, but then I realised that it was caused by the large amount of debug logging generated by these debug versions of the files.

MP (and Windows) are installed on a relatively slow Western Digital Green drive, which I guess is too slow to accept the debug output without causing the micro stuttering. Reverting logging to ERROR level cured the stuttering . I would not consider the stuttering to be acceptable for long-term use, but I have no problem with it for a few days, if we can track down the cause of the video problem.

-- from CyberSimian in the UK

 

[bta489]

After a period of relative eventfulness in this matter, I now have a new set of logs. This time while sifting through TV recordings today. During this, I had Black screens, flickering image and normal playback.
As before I removed the sections where it repeats the same debug lines over and over (during normal playback) to cut down on filesize of MediaPortal.log. The other two are untouched.

Thanks again for taking the time and for your continued support, doskabouter

 

[doskabouter]

Indeed it's been a while, was more or less hoping the problem resolved itself
But these logs indeed contain a nice exception with stacktraces and linenumbers.
Will investigate soon

 

[doskabouter]

Hm, starting to see a pattern here:
the first value after "start drawtexture" is less than 2147483647 when the rest succeeds, but bigger when it fails.
My guess is that in DXNative.FontEngineSetTexture(ptr.ToPointer()); the pointer is somewhere handled as int32 instead of unsignedint32
Edit: do you happen to have a fontengine.log (same dir as other logs) to 100% confirm that?
Edit2: the fontengine casts this pointer to an LPDIRECT3DTEXTURE9 and only does low level directx calls with it, but it seems unlikely that this issue is in the directxsdk itself...

Edit3 :I think I fixed it.
If you want to reduce logging to ease testing, just let me know

 

[bta489]

New files are in place. I don't see much impact on performance from logging apart from an occasional stutter, which I can easily live with for now.

If this is still of interest, I checked my logs: Except for the last time, there was no fontEngine.log file present in the log dir. That last time there was one (filesize 150 MB ) with first line

22-05-2021 20:07:21.100 [157c]ERROR Fontengine:FontEngineDrawText3D(4) exception

and subsequently, repeated every other millisecond or so for about 2,5 hours this line (only difference is the timestamp)

22-05-2021 20:07:24.156 [157c]ERROR Fontengine:Ran out of texture vertices

The date is almost a week before, though.

€dit: I just started to play several videos, to see if I can provoke another incident (none so far) and it already feels a lot 'snappier'. The image seems to be rendered much faster now (almost instant), whereas before there was always a noticeable loading period.

 

[doskabouter]

New files are in place. I don't see much impact on performance from logging apart from an occasional stutter, which I can easily live with for now.

If this is still of interest, I checked my logs: Except for the last time, there was no fontEngine.log file present in the log dir. That last time there was one (filesize 150 MB ) with first line

22-05-2021 20:07:21.100 [157c]ERROR Fontengine:FontEngineDrawText3D(4) exception

and subsequently, repeated every other millisecond or so for about 2,5 hours this line (only difference is the timestamp)

22-05-2021 20:07:24.156 [157c]ERROR Fontengine:Ran out of texture vertices

The date is almost a week before, though.

it was just something that I saw in the code, but isn't really relevant now that i found the real cause

€dit: I just started to play several videos, to see if I can provoke another incident (none so far) and it already feels a lot 'snappier'. The image seems to be rendered much faster now (almost instant), whereas before there was always a noticeable loading period.

That has certainly nothing to do with my update...

 

[doskabouter]

Do you think it's fixed now? Then I can put this in the 1.28 release?

 

[bta489]

I'd say so, yes. I tested with as many different Videos as I could since your last updated files, and so far did not encounter the problem again. It's hard to make absolute statements, though, as the error only occured sporadically before. However, the Video-Playback still feels a lot snappier. That alone certainly is an improvement.
These past days the stutters increased, due to the intense logging. I just tried setting it back to 'Error' level, and the stutters are gone completely.

Thank you for all your efforts in getting to the bottom of this and fixing it.

 

[doskabouter]

Loading...

issues.team-mediaportal.com

and added to the next release of MediaPortal