(2014-03-21, 11:42)DBMandrake Wrote: (2014-03-21, 11:31)dmdsoftware Wrote: why is this thread marked solved? The last posts mention the problem persists and I see no solution. It's not just rtmp streams, even http streams. don't get me even started talking about https streams.
I'm trying to support an ecosystem of pis but I find it harder each day 
I haven't seen any problems with freezing when trying to seek within an http stream - as far as I know its only rtmp streams. (An http stream is not a "live" stream)
Of course some http streams can't be seeked because the server doesn't support http resume...
It's also not a Pi specific issue so it doesn't have any bearing on whether you use the Pi or not, it exists in all versions of XBMC. (I have the issue on my Mac)
I agree about the solved tag though - this issue is most definitely not solved and there is no end in sight yet.
What I've noticed though is that there is definitely some seeking issue that is pi-related. I've tested seeking on streams being transcoded from google drive (using google's service) on a linux install, and it never has an issue. I'm able to quickly move from start to any position in the stream, whether I do a direct seek or pause-and-seek. On the pi, I try the same thing on the same source and it will crash or freeze, especially the further out in the video I go. I've been able to seek say 10-15 seconds further without generating freezes or crashes, but if I try to say move out to 10 or even 5 mins out in the stream, it'll almost most likely be an issue, even if I do a pause-and-seek.
It's absolutely makes plugins like PseudoTV Live pointless on the pi. It does seeking everytime you change channels. it's almost constantly crashing. If the seek doesn't crash or freeze XBMC, it'll at least cause the audio to become garbled.
