Add new implementation of the tvheadend addon #370
Conversation
This is an attempt to fix several limitations within pvr.hts, and rather than try and rework broken code I've decided to start from scratch. Some basic boiler plate has been copied and clearly the code isn't miles different (since its trying to achieve the same basic goals) but it is a rewrite.
some warnings are still in place since I do intend to use the variables when I implement the functions. So they will serve as reminders.
…buffer.
I (and others) had completely failed to notice that the default buffer size
for the SyncedBuffer object that pvr.{hts,tvh} was using is ridiculously small
and thus could result in lost data (worse there was no error output - doh).
I have increased to unlimited length, its implicitly bounded by other things
and there is little point bounding it. If it were to fill indefinitely then
something would have to be seriously wrong and the system would probably
eventually crash for other reasons!
This appears to fix timeshift issues, I wonder whether it will fix other things
as well!
Sync PVR API changes and bump add-on
Fix playback of large recorded mkv files.
…, retention, priority properties of recordings and timers.
…ording-props [pvr.tvh] Added support for getting and setting startExtra, stopExtra, r...
does) which also makes the "ignore connection lost warnings" actually work
it's still using the connection (since the connection thread calls into CTvheadend after it has been destructed)
|
can you squash it and include the removal of pvr.tvh in the same squash. i'm not really interested in the history of what happened after it had been rewritten already. if it were a clean fork that was merged back in, sure, but it's not :) |
|
You probably mean the removal of pvr.hts? How do you want to handle that by the way, should we just remove the old addon and keep the name? That way everyone who's using it right now would be able to upgrade to it cleanly. |
|
@opdenkamp before I squash, could you take a look at Jalle19@f70feb9 ? This has never really been tested on anything except Linux and Windows so I don't know how the other threading implementations actually handle this. |
|
yeah, pvr.hts, not pvr.tvh :) Jalle19@f70feb9 isn't correct, as it doesn't deal with spurious wakes. that's what you need the predicate for. not sure how you're trying to use it now, but PLATFORM::CEvent might be what you need instead. |
|
btw, when you said that it was tested on Linux, it wasn't tested very well in that case ;-) |
|
We currently use it to wait for a state to change, see https://github.com/Jalle19/xbmc-pvr-addons/blob/342a0334eab21065e970e3129de57777e7619de1/addons/pvr.tvh/src/AsyncState.cpp#L48. Haven't looked at CEvent, will do. |
|
that's double wrong. you must hold the mutex locked before waiting on a PLATFORM:CCondition. the behaviour of this code is undefined. |
|
Okay, I'll look into it. |
|
friendly poke @Jalle19 to get the comment addressed and this rebased, so this gets included for I* |
|
Thanks, I have one PR pending that I'd like to get merged in one form or another before I rebase and squash this. Hopefully it shouldn't take too long. |
|
Replaced by #399 |
I rebased my fork on upstream a few days ago so I decided I may just as well post this as a PR so we can slowly start looking at it. I'm basing this off a separate branch so work can continue in the master branch meanwhile.
There are some few kinks to work out (some Windows-only compiler warnings) and the infamous timeshift bug.
@opdenkamp start reviewing whenever you feel like it. If you want me to squash anything already, please say so.