Posts: 580
Joined: Apr 2013
Reputation:
30
2014-09-20, 11:20
(This post was last modified: 2014-09-20, 13:51 by slices.)
I have a complete rewrite of the way we handle the local server and subtitles that should fix this, just checked in to github.
Posts: 580
Joined: Apr 2013
Reputation:
30
No idea what's going on. Can you confirm that line 25 of _main_viacom.py is 'class XBMCPlayer( xbmc.Player ):', and then post a log of the issue.
Posts: 580
Joined: Apr 2013
Reputation:
30
Goodish news is that I was able to reproduce this, although only once. I've added some additional logging around the stop/end events. Also try a different bandwidth it may be there is an issue with the stream you're using. The select quality option from the context menu is probably the easiest way of doing this since it will show you all the streams.
From what I saw in my own testing there is an interesting 'feature' here, in that normally with a stacked url if one segment fails if moves onto the next. It looks like a failed playback is a stop not an end so that kills the server and stops all playback. I don't think this is a problem since we're treating all parts of the stack as a single stream, but will result in some different behavior.
Posts: 580
Joined: Apr 2013
Reputation:
30
2014-09-21, 08:57
(This post was last modified: 2014-09-21, 19:02 by slices.)
Try the version in github with the extra logging. Need to see which event is triggering the stop server call. I think what is happening is a difference between xbmc builds. On my windows system, I only see stop events when I push the stop button, and end playback events at the end of segments.
Need to see what else is going on so I can confirm this, and work out when a stop isn't really a stop.
Posts: 580
Joined: Apr 2013
Reputation:
30
Are there any event messages in the log