[jajoflo]

What would you consider the minimal functionnality for series recording?

I did implement the series recording for my self:
From TV Guide or TV Guide search the Record Serie context menu is available.

The menu open a dialog to select the "Rules" or "Filter" to use. The list display only the rules supported by the back end. In My case MePo I only have one choice "On this channel only"

• On this channel only.
  
• Skip repeat
  
• In Time range
  

Now I want to know if it's worth it to give it a couple more hours of work and if there's some other quick hit that i could address at the same time. Keep in mind that it has to be very easy to use. (My wife has to be able to set Serie recording by her self.)

I know very well what we can do with MePo and I've looked at 4TheRecord but I have no idea of the kind of rule you can set with the other backend would this functionnality helpfull?

[tsp42]

It would be usefull for the MythTV addon. Another way to do it would be to ask every time a series was scheduled for recording if all episodes should be recorded.

[jajoflo]

Another way to do it would be to ask every time a series was scheduled for recording if all episodes should be recorded.

If the backend does support Recording a serie but no other rules then I ask for a confirmation to record all episodes.
otherwise I will show up something similar to this:


Note that only rules supported by the backend will be display.

Myth documentation

Week Slot -- this records a show whenever the title is listed on the same channel, weekday and time. Note that if the TV station changes the schedule for a special episode, it would not be recorded. However, you can use a Single record for the special episode.

Time Slot -- this records a show whenever the title is listed for the time and channel on any day of the week. Here again, a show will not be recorded if the time was altered by the station.

Do you have more flexibility than that using Myth api? I'm trying to get the list of recording rules used by the different backend, it's not always obvious just with the documentation.

[opdenkamp]

I'm open to proposals. Just create a github ticket for it

[mssoftware]

Isn't it possible to do this more "generally" for all pvr clients/backends? I think, why does the backend need to handle the complete series recording stuff. Sure, it's a backend task, because you want to record new episodes even when you don't have the xbmc-frontend running.

But in my opinion, scheduling those recordings can or should involve user interactions. Mainly because of concurrent plannings and concurrency resolving. So it's good to schedule this on a frontend. Or have a four-tv-card setup

Some deeper digging into this:

1. tvheadend can't solve series recording, today. The backend can handle "Automatic Recording" by "Title", but this is not a solution. Using this is not episode-aware. So if you schedule automatic recording of a series you get everything scheduled regardless wether an episode is repeated the same night or if it's already in your archive.
2. tvheadend-HTSP protocol can't solve this, too. First of all the dvrCreateEntry-function can only be used on one EPG event. But the second problem might be, tvheadend-epg does not supply episode-numbering from it's epg data to XBMC.
3. I don't know about MythTV-EPG.

To get true series recording on tvheadend would implies:

1. Changing the HTSP protocol.
2. Fixing all bugs around those episode numbering in tvheadend (i just started, yesterday).
3. Extending tvheadend to make episode-aware recordings.
4. Have tvheadend be aware of which series/episodes are already in the video archives (!).

Oh no. My idea to handle this easily is in the moment:

1. Write a new PVR-Client (i'm just doing it as a test). This one is called „PVR-XMLTV“. It's just there to import the XMLTV-Data again into the XBMC-Database, even if the tv-backend could supply it.
2. With those new meta-data we could even display more and a nicer EPG in xbmc with episode numbering information, even when we are connected to a backend, which does not support it.
3. The new (or maybe a second) PVR-Client could supply a „Menu-Hook“ called „Record series“. I did not testet it, but it seems that those "Menu-Hooks" are implemented right now?
4. It can than use the XBMC-EPG-DB to find future episodes of the series.
5. It can display concurrent recording problems instantly to the user, to let them decide, which movie/or series should be recorded.
6. It could manage an ordered list of series-priority (like Win-MC).
7. It could schedule the recording over any (!) of the other installed PVR clients/backends.

The problem:

1. One XBMC in the home network has to run each 14 days.

Adding some thoughts:

1. If we have such an amount of meta data in XBMC, we could easily decide, which tv-recording is a series and which isn't. We do not need to post-process recordings or split them in separate folders for "TV-Shows" and "Movies".
A filtering directory provider could combine all those meta-data and give back a "pvr://recordings/tv-shows" and "pvr://recordings/movies". Any scraper would run fine, even on the pvr-recorder-streams.

Upstream-Link for tvheadend: https://www.lonelycoder.com/redmine/boar...opics/4365

[tsp42]

The supported scheduling types on MythTV is descriped in the wiki. I think it would be better to offer an addon specific dialogue to select between the different scheduling types as the backend support for scheduling is very different. See this thread for some more information about the issue.

[mssoftware]

Thanks for the link.

And you are right, i should re-think if i will give XBMC the power of scheduling any recordings. But with all those problems in those interfaces. I feel its the easiest and long-term-running solution.

We could add a capatibility "mCanRecordSeries" into the pvr clients. If one supports that capatibility, series record handling would be forwarded to the backend. If it is not handled by the concrete pvr client implementation, the base class for pvr clients should implement a generic approach, using xbmc epg data.