Problems with skipping during timeshift multiseat (4 Viewers)

[infinite.loop]

Hopefully the SMB ts-buffer rollover problem is fixed in the next build then, so we can switch away from RTSP in multiseat.

Be aware that the team does not give any support for those who use the SMB - HACK in multiseat.
This option is only there for testing and debug reasons!

 

[Wondermusic]

AW: Re: Problems with skipping during timeshift multiseat

I believe this is a big problem so here are my logs.
client and server.
multiseat
client is not in the same computer as server.

steps:
16.15 start timeshift
16.22 2xstep back (shows -30sec) (but does not do it) NOK
16.22 2xstep back (shows end) (but it shoulnt) NOK
16.23 2xstep back (shows -30sec) OK
16.23 3xstep back (shows -1min) OK
16.24 steps forward (shows end) OK

if there is any official steps to follow please tell me as i didnt know how to test it correctly, hope the logs are of any use.

btw, although im sure its somewhere in the logs. im using SVN from 24/12/09 24553

Have the same thing here since i installed a homeserver (previously everything was in my htpc: server/client and all went fine).

start timeshift
2 steps back (shows -30sec) - done nothing
2 steps back (shows End) - done nothing
Back to beginnig (Shows Beginnig) - OK
2 steps forward (shows +30sec) - OK
2 steps forward (shows +30sec) - OK
Forward to End (shows End) - OK
2 steps back (shows -30sec) - goes back about 45sec

waiting 2 min.

2 steps back (shows -30sec) - done nothing
2 steps back (shows -30sec) - done nothing
Back to beginnig (Shows Beginnig) - OK
5 steps forward (shows +3min) - forwards nearly to end
Forward to End (shows End) - OK

I' ve tried to make the logs with Watchdog, but when it is gathering system eventlog information it hangs. Waited for about 10min. but nothing. I aborted it and copied the logs manually. Hope you can use them...

Tested with SVN 24669 on my Office- Computer (Win7 x64, 4GB DDR2, Intel E7200, ATI 4870, SAF installed)

Greets,
Wondermusic

 

[infinite.loop]

Wondermusic
https://forum.team-mediaportal.com/556597-post27.html

 

[Guzzi]

AW: Re: Problems with skipping during timeshift multiseat

Hopefully the SMB ts-buffer rollover problem is fixed in the next build then, so we can switch away from RTSP in multiseat.

Be aware that the team does not give any support for those who use the SMB - HACK in multiseat.
This option is only there for testing and debug reasons!

Hi Chris,
to fully understand: What is the "official way" to get thumbnails for TV-recordings and comskip on recordings to work in a multiseat environment with no client running on the server?
Thanks, Guzzi

 

[infinite.loop]

Re: AW: Re: Problems with skipping during timeshift multiseat

Hopefully the SMB ts-buffer rollover problem is fixed in the next build then, so we can switch away from RTSP in multiseat.

Be aware that the team does not give any support for those who use the SMB - HACK in multiseat.
This option is only there for testing and debug reasons!

Hi Chris,
to fully understand: What is the "official way" to get thumbnails for TV-recordings and comskip on recordings to work in a multiseat environment with no client running on the server?

Both is a singleseat feature, which can be used in multiseat by enableing the SMB - HACK.

Thats also why both features are not officially supported in multiseat - and wont ever be in MP1.
:sorry:

 

[Wondermusic]

AW: Problems with skipping during timeshift multiseat

Hi all,

i have tested again...

After installing SAF beta23test3 i run DasErste HD and the jumps are correctly done by the engine.
I tested it with SD- Channels and it jumps nearly to the right positions and I have not the big problem i wrote before.

Is there someone who can confirm this?

 

[infinite.loop]

Re: AW: Problems with skipping during timeshift multiseat

Hi all,

i have tested again...

After installing SAF beta23test3 i run DasErste HD and the jumps are correctly done by the engine.
I tested it with SD- Channels and it jumps nearly to the right positions and I have not the big problem i wrote before.

Is there someone who can confirm this?

Just test more and you will still encounter it.
Because, as our developer has allready mentioned a few posts earlier, the current time position in the stream is getting greater than the duration of the stream, and no codec on the clientside can fix that.

Someone needs to find the reason for this randomly occuring bug, and fix it. Thats the only solution. Sadly our devs ran out of ideas on that matter.

 

[chrholm]

Seems elliottmc found a fix for this. Can't wait to tryout 1.1 RC. Thanks for the effort guys!

 

[mcmanuss8]

Excellent! I've been suffering from this, will try to install latest SVN this weekend and do some testing.

 

[romuz]

its not in public svn yet.