[Finished] Improvements to Live TV playback rate matching - for testing (3 Viewers)

[mm1352000]

@Owlsroost
I'm monitoring this thread with interest.

Wondering about how I'm going to [eventually] reconcile changes to TsWriter into TVE 3.5. The 3 classes you've currently modified - DiskRecorder, FileWriter and MultiFileWriter - are fairly significantly altered in my working branch. I actually attempted to implement async file writing too based on WriteFileEx():
https://github.com/MediaPortal/Medi...DirectShowFilters/DvbCoreUtils/FileWriter.cpp

Hopefully we can co-operate.

P.S. I'm not expecting a reply. Just hoping you'll keep the potential issues with changes to TsWriter in mind.

 

[Owlsroost]

@Owlsroost
I'm monitoring this thread with interest.

Wondering about how I'm going to [eventually] reconcile changes to TsWriter into TVE 3.5. The 3 classes you've currently modified - DiskRecorder, FileWriter and MultiFileWriter - are fairly significantly altered in my working branch. I actually attempted to implement async file writing too based on WriteFileEx():
https://github.com/MediaPortal/Medi...DirectShowFilters/DvbCoreUtils/FileWriter.cpp

Hopefully we can co-operate.

P.S. I'm not expecting a reply. Just hoping you'll keep the potential issues with changes to TsWriter in mind.

Actually, the threaded timeshift file writing only got 'released' almost by accident - I was playing with it (just to see how well it worked vs. the standard version) at the same time as this thread started.

When I realized that I needed to modify TsWriter to test some of possible fixes for the problems with remote reading of the timeshift files via SMB, I used the version I had in the experimental branch at the time - which just happened to be the version with threaded file writing....the rest is history...

(I thought I was fairly safe with modifying MultiFileWriter and FileWriter because they are only used for timeshift file handling, and are self-contained to TsWriter. I went down the 'threaded' route because it offered more of what I wanted to achieve with less effort)

 

[Palm_Maniac]

Hello There,

Here are the latest logs from day before yesterday and yesterday. Look at times the evening hours as from 20: 15h on, there occurred sometime then the pixelation on. Previously, nothing more. As soon as I but then zap evening beginning, they eventually go off again. Still images, there is no more.

The day before yesterday I thought it was over with the pixelation. The grin grew wider. And then I turned intensively to other stations, a short statue and then shortly after came verpixeln the first. As if the TSReader had something taken from the tread.

I hope you can do something with the information.

 

[Owlsroost]

And then I turned intensively to other stations, a short statue and then shortly after came verpixeln the first

Do you know what time the 'short statue' happened on the day before yesterday ?

How long was the 'short statue' ?

Does 'short statue' = pause of the video and audio ?

 

[Palm_Maniac]

Do you know what time the 'short statue' happened on the day before yesterday ?

Unfortunately no longer accurate. I think sometime 9-11 clock in the evening. About one second took the statue. Again it was like pressing the pause button.

Yesterday there was no still images but sporadic pixelation and tonight we had already pixelation. Funny, the whole afternoon it was perfect and now from 19h, 19: 30h they occur sporadically on again. But with long pauses in between.

 

[Owlsroost]

@Palm_Maniac - attached are a new TsWriter (for TV server) and TsReader (for client) for testing.

These revert the timeshift file caching behaviour back to how it is in the standard versions (but with no pre-allocation of the files, like the previous version). TsReader also has extra logging to show the worst-case access time for disk reads. This should show if the 'pauses' and pixelation are due to long access times (i.e. TsReader isn't getting the data quickly enough).

 

[Palm_Maniac]

Hi,

Here are the logs from yesterday with the new TSReader and Writer. Everything went absolutely error free from noon until evening. Against 20:13h, we have switched to our series. The picture went on normally, then a 1-2 second stutterer and from there it was again pixelation sporadically, but in large intervals. I then test times as stopped all live stream and restart to see if it has an impact on the frequency. In fact, the frequency of pixelation has decreased. I think it took only 1, 2 times on.

I hope you can do with the information and logs something. Why it runs several hours properly then suddenly reappear after a switchover. I will put on a RAM disk for testing the Timeshift buffer again today. Let's see if this affects somehow again.

 

[Owlsroost]

@Palm_Maniac

Thanks for the logs.

These kind of messages are quite interesting: "Demux : Audio to render too late= -0.209 Sec, FileReadLatency: 360 ms" - it means that it's sometimes taking a long time for data to get back to TsReader when it reads the timeshift buffer files....typically in your log the 'File Read Latency' is about 10-20 ms.

I get about 40-60 ms typical latency using WiFi + Powerline networking, with peaks to about 300 ms, but then I expect WiFi to have much worse performance than a wired network like yours. Playing HDTV at 5 Mbs on my laptop is working really well for me.

Do both your clients have the pauses and pixelation ?

Attached are new versions of TsWriter and TsReader.

TsWriter v3.1.31.6 has the 'file parking' removed (I don't think it makes any difference), and all timeshift files are are written in 'random access' mode. This seems to be the most reliable setup in my testing.

TsReader v4.1.0.14 reads all timeshift files in 'random access' mode, and has changes to minimise the operations during 'refresh' of the timeshift files. Basically I'm trying to reduce the network traffic to the minimum.

 

[Palm_Maniac]

Hi Owlsroost,

Do both your clients have the pauses and pixelation ?

Attached are new versions of TsWriter and TsReader.

Yes, both clients have the pauses and pixelation. I'll install the new versions of the same tomorrow and test. Thanks for that. I also again the Timeshift memory placed on a ramdisk with the result that the pixelation have minimized somewhat. Let's see what effect the new versions. I'll call then the day after tomorrow with the results.

 

[Palm_Maniac]

Hi Owlsroost,

it is to despair. No change for the latest files, there remain pixelation. Only the short pauses no longer appeared since I the Timeshift memory back to a ramdisk am running.

I do not understand. On the client only runs Windows and Media Portal, otherwise absolutely nothing that could disturb the network transfer. Also runs on the server absolutely nothing which might cause some sort of internal network traffic. I have in a player Forum instructions for configuring network cards found what you should perform when it comes to frequent lags. This I'm going to perform on the client and on the server and see if and how it affects. I will report.

I noticed is a bit recently. I cut my recordings on my PC and then copy the files over the network to the hard drives on the server. So far I could copy the files without which it has had a negative impact on the television sector. Now if I copy a file, there is such an extreme interference with the TV that a problem-free TV viewing at this time is no longer possible. Does this observation anything to do with the problems causing the pixelation, or I'll just slow paranoid?

New logs I have again attached, but I think they only show once again the same as the others, but I always hope anew that you still find something. Hope dies last known.