HELP US: Testing the new filter

[chrissooo]

Hi all,
for first i must say that at the moment the TV-Server / MP with TSReader works great.

But sometimes i have a isue. When watch long time TV and the timeshift files are full i have sometimes the problem when i change channel, MediaPortal do for 1-2 Minuts nothing, only i hear the CPU Fan working. After this time MP playing the start of the timeshifting.
I thing MP lost the position in the timeshiftfiles and try to find. After this 1-2 Minutes he start at the begining of the timeshifting.

This happen not very offten, but its happen ... i will try to get logfiles, but for every time when i see it, my wife watch tv and i cant do it.

Have someone the same isue?

[pnyberg]

Well, I suspect I too have experienced the same issue.

But since I set my timeshift files to be 2000 Mb each and then remove all the *.ts files during a scheduled job during the night, I haven't experienced the problem anymore.

So I would suppose it is a real issue when "rolling over" the .ts files.

But for now I am happy with my workaround - since I don't currently have the time to debug the issue...

[Seidelin]

Originally Posted by chrissooo

Have someone the same isue?

Yes. I do. After these long timeshifts, I have slow seeking (~1 minute for a seek).

Regards
Seidelin

[Seidelin]

I just did another test about this issue (slow seeking after timeshifting for extended time). Setting the timeshift files to min 60, Size 1 MB makes the error occur much faster. A seek causes ~200 MB to be read from the disk. Considering the timeshift buffer is only 60 MB total, this should not happen. For large buffers the amount of data to be read multiple times are larger, causing these excessive seek times. A workaround (if you have the diskspace) is to have many large timeshift files, so the files don't need to be recycled.

Edit: After letting the same files timeshift for 50 minutes, a seek causes 2.7 GB to be read.
Conclusion: The files are read through as many times as they are recycled.

Regards
Seidelin

[Eabin]

just had the same issue here. didn't know that i could just wait and the seek would complete eventually, i just thought MP had gone bonkers and killed it it did use 100% CPU on one core too.

[phunqe]

Whats' the status on using ffdshow with TsReader?

[peque]

Originally Posted by phunqe

Whats' the status on using ffdshow with TsReader?

Did the same question some time ago... no answer atm...

[tourettes]

Originally Posted by peque

Did the same question some time ago... no answer atm...

Still not supported. I guess the main reason for not allowing ffdshow to decode mpeg2 content is that ffdshow doesn't seem to handle the SD to HD transitions. So we don't want to have any codec related issues to reported us.

Currently there is enough open issues to keep the team busy, so I won't even think about changing the ffdshow policy inside TsReader.

If someone really want's to test the ffdshow please read from MP wiki how to compile directshow filters and have a look on the TsReader - CVideoPin::CheckConnect() method.

[peque]

I agree that ffdshow is NOT the best mpeg-2 decoder at all... Seeking is quite buggy, for example... This policy is not that bad, as I can add ffdshow as postprocessor filter and de-interlace tv content using it. Just wondering why you were preventing it to connect to tsreader!

Thank you very much for your answer.

[chrissooo]

hi again,
now i have reproduce the problem who happen when the timeshiftfiles recycle.
When this files are full and receicle some times there is the problem with channel change.
MediaPortal starts at the beginning of the timeshifting.
On my test i set the timeshift file size to 10MB, becouse so i can reproduce it faster.
When i set the filesize normaly like 256MB, MP make the same, but much later and it takes very long to change the channel when this isue start. About 1-2 Minutes. I thing MP loose the position on the timeshift file and start at the beginning after a long time searching,

Please show on my logfiles.
It happens on the last channel change,