[Approved] Fix for stuttering/corrupted streaming of live tv (1 Viewer)

[disaster123]

AW: Fix for stuttering/corrupted streaming of live tv

that's it - only NTFS supports sparse. Even when my new patch does not make the use of SPARSE i think NTFS would be faster than FAT32 for timeshifting. I'm not quite sure if FAT32 supports preallocated files without filling the files with 0... perhaps tourettes knows it.

 

[romuz]

ill try with ntfs but for imho ramdrive it is not a problem to fill all by 0

 

[tourettes]

that's it - only NTFS supports sparse. Even when my new patch does not make the use of SPARSE i think NTFS would be faster than FAT32 for timeshifting. I'm not quite sure if FAT32 supports preallocated files without filling the files with 0... perhaps tourettes knows it.

Sparse files should be as fast / slow to be created as the conventional ones. But I'm not 100%, so we should build a test application that creates 50GB file with both options. Then timing that creation time for 10 times and calculating the differences.

ill try with ntfs but for imho ramdrive it is not a problem to fill all by 0

I'm quite sure that the file creation speed has no role in the issue we are seeing but instead the SMB cache that wont get updated and the file is not available to the client side even when the server side has the file available.

 

[pilehave]

I'm quite sure that the file creation speed has no role in the issue we are seeing but instead the SMB cache that wont get updated and the file is not available to the client side even when the server side has the file available.

Could this be fixed by calling the file on forehand, say 60 seconds before the real access is about to take places?

 

[disaster123]

AW: Re: Fix for stuttering/corrupted streaming of live tv

that's it - only NTFS supports sparse. Even when my new patch does not make the use of SPARSE i think NTFS would be faster than FAT32 for timeshifting. I'm not quite sure if FAT32 supports preallocated files without filling the files with 0... perhaps tourettes knows it.

Sparse files should be as fast / slow to be created as the conventional ones. But I'm not 100%, so we should build a test application that creates 50GB file with both options. Then timing that creation time for 10 times and calculating the differences.
.

I've tested this while working on my DS filter. At least on FAT32 it takes really long to create a 4GB file (without sparse as it is not supported). I'm not quite sure if SPARSE will have any influence on NTFS.

I'm also quite sure that the problem is notrelated to SMB file caching. As it happens at least to me mostly when the tsbuffer file changes. I'm also seeing discontinue errors at the client at that time but not on the server.

 

[DJBlu]

Correct me if I'm wrong but 8gb on FAT32 isn't possible is it?

 

[disaster123]

AW: Fix for stuttering/corrupted streaming of live tv

sorry meant 4 uups

 

[arion_p]

Re: AW: Re: Fix for stuttering/corrupted streaming of live tv

I'm also quite sure that the problem is notrelated to SMB file caching. As it happens at least to me mostly when the tsbuffer file changes. I'm also seeing discontinue errors at the client at that time but not on the server.

SMB file caching has everything to do with the issue. When the tsbuffer file changes, the change should be immediately visible to the client but instead the client sees the cached data. Simply put, SMB is not suitable for this and that is why it is not supported.

 

[disaster123]

AW: Fix for stuttering/corrupted streaming of live tv

arion_p
OK - same question, i already asked to tourettes, to you. What should the users use instead? rtsp implementation in MP / TsReader is even more buggy than SMB. There are very often loops when the audio / video changes. That's even more worth than sometimes stuttering. Except you're just watching SD with MPEG audio.

 

[mylle]

Re: AW: Re: Fix for stuttering/corrupted streaming of live tv

I'm also quite sure that the problem is notrelated to SMB file caching. As it happens at least to me mostly when the tsbuffer file changes. I'm also seeing discontinue errors at the client at that time but not on the server.

SMB file caching has everything to do with the issue. When the tsbuffer file changes, the change should be immediately visible to the client but instead the client sees the cached data. Simply put, SMB is not suitable for this and that is why it is not supported.

Is it not possible to work around this?