NPVR database - why so stringy with the fields?? :0)

[carpeVideo]

I have been poking around the new database structure to update guidePlus and vidImport.

One thing they both do is a query on the database to get a list of upcoming or previous recordings that are TV series - for renaming and adding extra EPG info etc.

This was a very simple query before - Just look at recordings joined with the epg where the unique_ID starts with EP (at least with schedules direct data)

Now already recorded shows save their data in a field embedded in XML and these recordings have lost their unique IDs and a host of other data, so I would have to pull the epg_ID out of the XML link it the EPG table and hope that it is still in the there, then check if it is a series.

So, I guess my wish for this task is to see the unique program ID saved as a field for scheduled_recordings (which would also allow easily allow not recording dups again as well).

But in general it begs the question why so stingy with fields. If you don't want a titles data in the EPG after its time has passed why not just another table (completed_events/scheduled_events?) with a full set of fields that the scheduled_recordings could link to. Just my two cents but it seems the stored XML offers little in the way of advantage and limits what the database can do.

Thanks for all your effort and the new toy BTW!!

[sub]

GBPVR had endless problems caused by the requirement to leave the details in the PROGRAMME table for any shows linked to a scheduled recording, and it made things awkward for importing recordings where a matching channel didnt exist, when the user wanted to delete channels but they were referred to via the RECORDING SCHEDULE link to the PROGRAMME table. ie, the database would end up listings from today for a week or so, then just a small splattering of old listings in the past that were used for a recording at the time.

The new scheme is much better and does away with these problems by storing a cached copy of the show details in the recording, including the channel name etc, allowing recordings to exist in the database even when all the listings or channels are deleted, simplify importing etc.

Sorry, but I have no plans to change it back to the old problematic scheme.

[mvallevand]

I thought I was the only one. I would love to have all the fields copied to matching fields after a recording. They should be able to coexist with the xml field with minimum impact of size. Not recording duplicates cold be implemented with simple logic based on a new status code and the unique ID. It's true that not all xmltv sources provide what is available here but it would be great to have more flexibility.

Martin

[carpeVideo]

GBPVR had endless problems caused by the requirement to leave the details in the PROGRAMME table for any shows linked to a scheduled recording, and it made things awkward for importing recordings where a matching channel didnt exist, when the user wanted to delete channels but they were referred to via the RECORDING SCHEDULE link to the PROGRAMME table. ie, the database would end up listings from today for a week or so, then just a small splattering of old listings in the past that were used for a recording at the time.

The new scheme is much better and does away with these problems by storing a cached copy of the show details in the recording, including the channel name etc, allowing recordings to exist in the database even when all the listings or channels are deleted, simplify importing etc.

Sorry, but I have no plans to change it back to the old problematic scheme.

I understand the issue from before - that is why I suggested keeping a new copy in another table as fields not XML (or as fields directly in scheduled_recordings), it would solve the same problem without creating others because there would be no channel link. The problem before was not that you didn't use XML , it was that there was no copy once a recording was done that could be decoupled from a channel.
or
If not can you at least keep the unique ID in the XML - then a like '%<unique_ID>EP%' would do the job although that is a long query for sqllite.

[sub]

If not can you at least keep the unique ID in the XML - then a like '%<unique_ID>EP%' would do the job although that is a long query for sqllite.

I do intend to do this when I add built in Schedules Direct support.