2012-10-28, 23:34
(2012-10-28, 23:20)janbar Wrote:(2012-10-27, 21:50)Aubrien Wrote: With regard to having to stop and restart playback every 2 hours, I bet the buffer dries up and then you hit the buffer code that doesn't work very well for me either. When you stop and restart playback it fills the buffer from scratch again until it runs out again in another couple hours. When the addon reads 0 bytes from the backend it chokes up and doesn't always recover. I havn't heard of a fix for this yet except when I was playing around and reworked the buffer code not to read if there is no data available. I didn't let the read operation progress until the file had at least a certain size. This was so many versions ago that my method would have to be reworked again. I still believe that having the frontend try and force its way through reading 0 bytes of data is not as good as preventing the read 0 bytes in the first place.
@janbar
Any chance of reworking the buffer code to avoid the reading of 0 bytes in the first place? If you have a delay between shows or long channel changes then you hit the buffer code and it doesn't work very well. Thanks
Hi aubrien,
Every days i think about your case. I can not explain why a "Read 0 bytes" is a problem. At each stream read addon try to query a block of bytes from backend. After trying for 30 seconds (because we added sleep for 0.5 s for each try) XBMC close playback. I think to simulate your case on my config using a stub of code.
Nota: The "Read 0 Bytes" is like a signal to tell us:
- get smaller block of bytes
- try to switch next file from chain if exists
- Retry read later because i am overloaded and i cannot send more bytes now
Sure, there is a bug somewhere. I found one and i suspect it comes from Myth (the case above when show stop). But i must check why. It could be an issue about how we implement the protocol. I am looking for.