[pvr.hts] fill the VFS buffer on a separate thread #404
Conversation
Jalle19
changed the title
|
just one question: do we really need a setting for this? |
|
@opdenkamp personally I'd say we don't, it was Adam's idea to add it. I'm afraid some users will see it and think "wtf I don't want any extra buffering", turn it to zero and watch their recordings stutter. If @adamsutton is fine with removing it then I'll remove it. |
|
@opdenkamp @Jalle19 it's probably overkill, drop it. |
|
Something feels a bit wrong about the condition handling, I'm not convinced about it being used in both directions (though I'm not really sure why). And I'm not sure we need to stall in the read() call unless there is NO data available. I'm feeling like shit today though, so I really can't focus on it properly, I'll try and take a look in a couple of days. |
|
If we return |
|
@Jalle19 I wasn't suggesting that, I was suggesting that you return as much data as you can while asking for more. However I think that's also probably wrong, Kodi will probably assume that if we return less than it asked for that that indicates the end of the file. So probably fine as is. Clearly my brain is seriously addled today! |
|
not so sure about that, i haven't checked, but i think len is just the maximum read size (size of the buffer) and returning less is probably fine. though it'll probably just lead to more hammering on this method :) |
|
I say we play it safe and continue with the old behavior (only return if we can return the requested length). |
Jalle19
force-pushed
the
vfs-thread-buffer
branch
from
d2c320b to
8bb1e03
Compare
|
I dropped the setting. |
|
squash and merge away, before we copy stuff over to a new repos ;-) |
|
I haven't had time to test it extensively yet, I can try to do that tonight. |
|
Tried to backport this to a Helix compatible addon but only got lots of missed packets and crap like that. Don't know if I did something wrong yet or if this just doesn't work. Will need to try on an Isengard Kodi to be sure. |
Jalle19
force-pushed
the
vfs-thread-buffer
branch
from
9d4f7c1 to
eefdf85
Compare
|
Found the bug, it was something I introduced last minute. This works fine now on Windows. |
gradually increase the read chunk size (allowing for more jitter in the latency between client and server) gradually without making the reader wait for the full chunk to be received. The read length is reset during seeking and if the buffer happens to run dry (ffmpeg does around 10 short seeks for each seek request so it helps to keep the read size small).
Jalle19
force-pushed
the
vfs-thread-buffer
branch
from
eefdf85 to
7cc5109
Compare
[pvr.hts] fill the VFS buffer on a separate thread
@adamsutton can you review this? I'll start testing it at home tonight, I have to upgrade my HTPC anyway.
@opdenkamp you can also take a look if you have time