- June 13, 2006
- 979
- 178
- Home Country
-
Belgium
The story so far:
There has been some talk here about smart scheduling before, and how changes to the scheduler affect MediaPortal.
Having tweaked the system currently in MediaPortal I have come to realize there's a lot of interdependant code in there. Scheduling logic is duplicated in many places for example, and everyone (plugins, TV plugin, remote clients,...) accesses the MediaPortal TV library and scheduling database directly.
The (possible) future:
What I would like to propose is a TV-guide and scheduling subsystem that would talk to the outside world over a web-service.
The idea is to keep the guide and scheduling stuff separate from other recording and tuning stuff. Currently this line is very fuzzy and I think we could get a much more reliable system if we keep them clearly apart. One sub-system can the be changed/fixed/improved much more easily with much less impact to the rest.
Using a web-service is a very conscious design choice since I would like to keep this guide/scheduling-service totally on the server so MediaPortal clients would not contain any duplicate code and would also not access the database remotely nor directly.
Using WCF (.NET 3.0) it's possible to wrap all the above in a single window service, just like the TV service itself is a service today. Or we could combine the two if the idea of two windows services is not to everyone's liking.
The windows service would host the web service (meaning there's no need to have IIS on your media server) and could also take care of importing XMLTV data when it appears. If one does not use XMLTV and has the guide data come in over DVB e.g., the TV service could feed the Guide service the program data. In case you have NO guide data, the guide will simply remain empty and only the scheduling logic will be handled.
Channels could be identified to the outside world using a GUID and in the MediaPortal database we can link the rest of the channel data (for tuning e.g.) to this totally unique ID.
Schedules can be completely managed by the TV-guide and scheduling service, all the TV service would have to do is get the list of upcoming recordings from the scheduling service and simply record what is queued (if it can).
Implementation:
Since I propose this as a separate sub-system it would be easy to develop this side-by-side and only switch the rest of MediaPortal over to it when we feel it is stable enough to handle the job. This could definately minimize the impact. Unfortunately it would eventually mean a database change of course, at the moment of switching.
Feedback:
I hope to get some feedback on this idea
Especially from the MP developers. What's the feeling towards such an overhaul of the TV library and scheduling system?
Conflicting schedules is an interesting issue I'd like some feedback on. This would most likely be the responsability of the TV service rather than the scheduling subsytem, since only the TV service knows how many recording cards there are to record two programs simultaniously.
So the scheduling service would provide the optimistic handling of everything, assuming everything is recordable all the time, and the TV service itself can provide the logic to add a conflicing "flag" to the upcoming recordings.
There has been some talk here about smart scheduling before, and how changes to the scheduler affect MediaPortal.
Having tweaked the system currently in MediaPortal I have come to realize there's a lot of interdependant code in there. Scheduling logic is duplicated in many places for example, and everyone (plugins, TV plugin, remote clients,...) accesses the MediaPortal TV library and scheduling database directly.
The (possible) future:
What I would like to propose is a TV-guide and scheduling subsystem that would talk to the outside world over a web-service.
The idea is to keep the guide and scheduling stuff separate from other recording and tuning stuff. Currently this line is very fuzzy and I think we could get a much more reliable system if we keep them clearly apart. One sub-system can the be changed/fixed/improved much more easily with much less impact to the rest.
Using a web-service is a very conscious design choice since I would like to keep this guide/scheduling-service totally on the server so MediaPortal clients would not contain any duplicate code and would also not access the database remotely nor directly.
Using WCF (.NET 3.0) it's possible to wrap all the above in a single window service, just like the TV service itself is a service today. Or we could combine the two if the idea of two windows services is not to everyone's liking.
The windows service would host the web service (meaning there's no need to have IIS on your media server) and could also take care of importing XMLTV data when it appears. If one does not use XMLTV and has the guide data come in over DVB e.g., the TV service could feed the Guide service the program data. In case you have NO guide data, the guide will simply remain empty and only the scheduling logic will be handled.
Channels could be identified to the outside world using a GUID and in the MediaPortal database we can link the rest of the channel data (for tuning e.g.) to this totally unique ID.
Schedules can be completely managed by the TV-guide and scheduling service, all the TV service would have to do is get the list of upcoming recordings from the scheduling service and simply record what is queued (if it can).
Implementation:
Since I propose this as a separate sub-system it would be easy to develop this side-by-side and only switch the rest of MediaPortal over to it when we feel it is stable enough to handle the job. This could definately minimize the impact. Unfortunately it would eventually mean a database change of course, at the moment of switching.
Feedback:
I hope to get some feedback on this idea
Especially from the MP developers. What's the feeling towards such an overhaul of the TV library and scheduling system?Conflicting schedules is an interesting issue I'd like some feedback on. This would most likely be the responsability of the TV service rather than the scheduling subsytem, since only the TV service knows how many recording cards there are to record two programs simultaniously.
So the scheduling service would provide the optimistic handling of everything, assuming everything is recordable all the time, and the TV service itself can provide the logic to add a conflicing "flag" to the upcoming recordings.