New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add trivial conflict checking #267
Conversation
|
@charrea6 one minor suggestion, can you rebase this to clean it up. But this definitely looks very interesting, we should probably have a chat about this. I've had plans (see https://tvheadend.org/issues/1087 - bit light on detail) to rewrite the DVR code for some time, just been bogged down with other stuff. This would almost certainly want to include conflict checking and better re-scheduling, among a whole host of other things. If you interested we could have a chat about it. Also I think that once the dvb rewrite is complete and we've had a chance to better abstract the DVB sources, some of this can be made a lot simpler. Adam |
|
+1 on adams comment |
|
Right, I've rebased I think (not that sure what I'm doing yet with git, more familiar with Clearcase UCM). Definitely interested in a chat about this... I'd implemented something similar for Freevo 2's recordserver (not committed) that did conflict detection and scheduled recordings by allocating a recording to specific devices. It turned out to be quite complex to do the allocation. If you do a best effort allocation you sometime need to remove conflicting recordings apply the new recording and then try and apply the removed recordings (possibly removing and reapply other conflicting recordings). I got it working but it was more complicated than I liked. |
|
Oh yeah I have a reasonable idea of how complicated it can get, I've been If you can, try popping along to #hts (freenode IRC). I'm usually about Adam |
b30f05b
to
1bd1564
Compare
This pull request add simple conflict checking to the web ui and to the HTSP server.
It works by retrieving all the scheduled recordings between 2 times and then attempting to allocate the channels that would be used by those recordings to devices. It doesn't currently take into account current state of the server (this could be added in the future).
I've tested this on a homogeneous setup where it will work best, however it should still work on setups that don't have multiplexes with the same services.