HELP US: Testing the new filter (1 Viewer)

[chrissooo]

Suggested workaround is to increase timeshift buffersize so no recycling will occur. MP doesn't freeze, it just reads through the timeshift files a few times before seeking finishes, as described in this post:
https://forum.team-mediaportal.com/showpost.php?p=202431&postcount=424

Regards
Seidelin

For me is unposibble, becouse when i look for exampl tv for 4-6 hours for exampl and most of the shows who i look is HDTV, i need about 50GB or more for Timeshifting. That hard.

I hope this will be fix next time, becouse that is my last problem with great mediaportal.

 

[vuego]

I don't know if this issue has to do with TsReader or to whole TV3...

I'm using ffdshow raw filter as postprocessing filter (for deinterlacing). After switching to SVN 16542 from 16098, when you switch from regular MPEG2 SD channel to a H264 HD one, ffdshow gets disconnected (I can see connecting to remote graph with graphedit)... What's more, when you switch back to a regular MPEG2 SD channel, ffdshow doesn't connect again. Same result if you start TV with HD channel and switch to a SD channel. Tried with Rebuild graph on audio and video specs change and without it. Tried with Cyberlink and CoreAVC (1.6) as H264 decoders... same result.

I attach log file of a zapping from a SD to a HD channel. I also attach error.log... It seems has nothing to do with the issue, though.

This is a merit issue. VMR9 has a higher merit than ffdshow by default which is why the video decoder instead connects to VMR9.
Eabin was looking at the issue but I don't think he ever found a solution. Check this thread https://forum.team-mediaportal.com/tv_postprocessor_does_not_reconnect-t30177.html

 

[peque]

This is a merit issue. VMR9 has a higher merit than ffdshow by default which is why the video decoder instead connects to VMR9.
Eabin was looking at the issue but I don't think he ever found a solution. Check this thread https://forum.team-mediaportal.com/tv_postprocessor_does_not_reconnect-t30177.html

Wow! I'm not alone!

I've posted there. Thank you very much for pointing me in right direction. Let's see if Eabin can help us.

 

[dalmer]

What is that all about? Is it seeking within the timeshifting files? I'm running with default timeshifting filesizes and I hadn't timeshifted(i.e. paused) or anything when this happened.

It is a known bug. Suggested workaround is to increase timeshift buffersize so no recycling will occur. MP doesn't freeze, it just reads through the timeshift files a few times before seeking finishes, as described in this post:
https://forum.team-mediaportal.com/showpost.php?p=202431&postcount=424

Regards
Seidelin

I think there are two bugs here. In Seidelin's case he found a bug when deliberatly timeshifting. SweMart is saying it started a timeshift seek even though he didn't do anything.

I have also seen this many times. A freeze when watching tv. The logs say it is due to timeshifting. It usually occours after switching to a new channel and then watching it for a while (several minutes). Could this be related to the channel switching bug that caused tsreader to start playing from the timeshifting buffer instead of showing the new channel? I thought this was fixed though. I still see it happen, but only when I change to a channel that can't be tuned in for some reason...

Thanks

 

[Seidelin]

I think there are two bugs here. In Seidelin's case he found a bug when deliberatly timeshifting. SweMart is saying it started a timeshift seek even though he didn't do anything.

I think it is the same bug.

Actually Swemart wrote:

Just noticed something interesting, sometimes when changing channels after having watched a channel for a long time Mediaportal seem to freeze.

The bug I described also happens when pausing or changing channels, I believe.

Regards
Seidelin

 

[Eabin]

This is because there is a seek happening as part of the channel change (seeking to end of the timeshift buffer file to make sure the user gets to see the channel change).

 

[chrissooo]

Becourse the Change at todays Build:
tsreader 26/11/2007 [13:04:42] Eabin added: fixed the slow seeking times that occured after timeshift buffer files were recycled

Now on channelchange the timeshift file will delete and start new ... the channelchanging takes now around 3 Sec ... it s much slower now.

 

[Seidelin]

Becourse the Change at todays Build:
tsreader 26/11/2007 [13:04:42] Eabin added: fixed the slow seeking times that occured after timeshift buffer files were recycled

Now on channelchange the timeshift file will delete and start new ... the channelchanging takes now around 3 Sec ... it s much slower now.

I don't see that (provide logs please). I see channel changes as fast as always, and the issue with recycling timeshift buffers is gone. Good work Eabin.

Regards
Seidelin

 

[chrissooo]

Here the logs ... i have test it at this morning and dont have time.

I have also test it with diferent codecs ... always the same.

 

[Seidelin]

I can't see any signs of channel change in above logs?

Regards
Seidelin