Update EPG with XMLTV data doesn't work

[next]

I'm executing Settings > Channels > Update EPG. This finishes suspiciously fast but without any error message. No data get's imported, TV Guide stays empty.

They same XMLTV data file get's imported by GBPVR correctly.

When I was setting up the Analog Recorder Device I could import the same XMLTV file to get the list of channel names, in the correct order.

What's wrong?

This is with NVPR 1.5.24 on W7 32-bit.

[sub]

Zip and attach your npvr.db3 and the xmltv file and I'll take a look.

[next]

Thank you.

The channel numbering may seem special: Two times I use the same number for two different channels.
The channels of a pair are broadcasted on the same frequency during day and night time.
The problem reported already occured with the original channel numbers after device setup. And in GB-PVR these doubly used numbers work.

[sub]

The problem is happening because your xmltv file only has start times for your shows. Normally an xmltv file would have both start and end times. GB-PVR was able cope with this but NPVR is not.

I'll add the support for xmltv files with no end time in the next release.

[sub]

Give this patch a go.

[next]

Now Update EPG works.

For a moment I had been wondering myself how GB-PVR or NPVR could know about the duration of a broadcast if there isn't an end time in the xmltv data. But naturally the start time of the subsequent broadcast is the end time of the one in question.
Im using the latest xmltv, 0.5.57, and it astonishes me that this seems to produce different output formats.

Some further feedback and suggestions:
- My first test was how NPVR would handle very long epg entries.
GB-PVR generates long file names, intangles itself with them and misses every subsquent pending recording - until restart, of the machine, not of GB-PVR, if I remember correctly.
NPVR generates long file names also, and records the broadcast without a problem!

TV Guide:
- Long entries should be displayed completely - by wrapping in the footer.
- I was irritated that xmltv data more than 24 h old wasn't imported. Then I understood why.
This led to the idea of an "eternal" tv guide where past broadcasts are not deleted.
- Highlighting of recorded past broadcasts would be nice.
- When scrolling to the right, up to the end of the available data, scrolling becomes faulty. As long some data is still on the screen the cursor jumps back when it arrives at the end. When no data is visible anymore one can not go back.
- When going up and down from station to station the cursor jumps backward and forward in time in a manner I don't understand.
- It is important to be able to jump forward and backward in whole days, and to jump to a specific date.
- Sometimes when going up towards the first station or down towards the last station I would prefer a stop at the edge instead of wrapping around.

Recording:
- It should be possible to record consecutive broadcasts on the same station gaplessly. In GB-PVR this is possible only by using manual recording and only one instead of two recordings. But one should be able to use the guide for this. NPVR could a) automatically make one long combined recording, b) two separate recordings with absolutely no missing part (they could be combined again) or c), the best way because of padding requirements, write the overlapping part simultaneously to two different files. Modern machines should be fast enough for this.
I was not able to quickly test how far this is possible already because I could not shedule a manual recording.

And while we're at it I allow myself a small digression :
VPS - Video Programming System for analog tv.
I read that you are not interested in it. But it is so important that you should open up a required interface and give somebody else the opportunity to implement it...

[sub]

- I was irritated that xmltv data more than 24 h old wasn't imported. Then I understood why.
This led to the idea of an "eternal" tv guide where past broadcasts are not deleted.
- Highlighting of recorded past broadcasts would be nice.

There is a really large amount of listing data, particularly in the US where alot of customers can easily have a couple hundred channels and 14 days of listings. Most people arent interested in listings in the past, so I thought its a better idea to remove the old listings to keep the database at a manageable size, and allow it to continue function at a decent speed.

- When scrolling to the right, up to the end of the available data, scrolling becomes faulty. As long some data is still on the screen the cursor jumps back when it arrives at the end. When no data is visible anymore one can not go back.

I'll check this out.

- When going up and down from station to station the cursor jumps backward and forward in time in a manner I don't understand.

When you press up or down, it select the first show it finds on the screen that overlaps with the time of the previously selected show.

- It is important to be able to jump forward and backward in whole days, and to jump to a specific date.

You can jump forward or back a day using the Skip buttons (Ctrl-RightArrow, Ctrl-LeftArrow). You can jump a page at a time using the ff/re buttons (Ctrl-F, Ctrl-R).

- Sometimes when going up towards the first station or down towards the last station I would prefer a stop at the edge instead of wrapping around.

Sorry, I prefer the TV Guide to wrap around, which is why it is the way it is.

Recording:
- It should be possible to record consecutive broadcasts on the same station gaplessly. In GB-PVR this is possible only by using manual recording and only one instead of two recordings. But one should be able to use the guide for this. NPVR could a) automatically make one long combined recording, b) two separate recordings with absolutely no missing part (they could be combined again) or c), the best way because of padding requirements, write the overlapping part simultaneously to two different files. Modern machines should be fast enough for this.

Assuming you have a digital tuner, if your record two consectutive shows on the same station, the NPVR can already record to both at the same time (on one tuner), ie if you schedule 8:00 - 8:30 with 2 minutes pre/post padding, and 8:30-9:00 with 2 minutes pre-post padding, then the first recording will end up contain 7:58-8:32, and the second recording will contain 8:28-9:02.

Manual recording are not currently implemented in NPVR, but you'll also be able to do that when its added soon, allowing you to record 7:58-9:02 instead if you prefer.

And while we're at it I allow myself a small digression :
VPS - Video Programming System for analog tv.

Sorry, I wont be adding support for this. Its not used in this part of the world, and analog is dying and not worth investigating the significant effort required for this feature. Its only mentioned about twice in the last 7 years, so its hard to give any priority to it.

[next]

There is a really large amount of listing data, particularly in the US where alot of customers can easily have a couple hundred channels and 14 days of listings. Most people arent interested in listings in the past, so I thought its a better idea to remove the old listings to keep the database at a manageable size, and allow it to continue function at a decent speed.

I understand.

When you press up or down, it select the first show it finds on the screen that overlaps with the time of the previously selected show.

I imagined something like that. But I had several situations where it did not work like this.
Just press up and down several times in a part of the guide a bit ahead of the current time and where adjacent stations have different broadcast patterns. Not only does the cursor not return to the same position in repetitions but it also jumps to shows with no overlapping with the previous ones.

You can jump forward or back a day using the Skip buttons (Ctrl-RightArrow, Ctrl-LeftArrow). You can jump a page at a time using the ff/re buttons (Ctrl-F, Ctrl-R).

That's good news.

Assuming you have a digital tuner, if your record two consectutive shows on the same station, the NPVR can already record to both at the same time (on one tuner), ie if you schedule 8:00 - 8:30 with 2 minutes pre/post padding, and 8:30-9:00 with 2 minutes pre-post padding, then the first recording will end up contain 7:58-8:32, and the second recording will contain 8:28-9:02.

Hm. That's exactly what I meant - except that I have an analog tuner.
Does it work for that also - assuming, that you abstracted this in a similar way as you abstracted the file format with the .ts files for both tuner types?
... well, I just sheduled a test...
Later: Ou, if my test is correct, it doesn't work for the analog tuner.

Manual recording are not currently implemented in NPVR, but you'll also be able to do that when its added soon, allowing you to record 7:58-9:02 instead if you prefer.

Will it also be possible to have two overlapping manual recordings (on one tuner)?

VPS - Video Programming System for analog tv.
I read that you are not interested in it. But it is so important that you should open up a required interface and give somebody else the opportunity to implement it...

Sorry, I wont be adding support for this. Its not used in this part of the world, and analog is dying and not worth investigating the significant effort required for this feature. Its only mentioned about twice in the last 7 years, so its hard to give any priority to it.

And that's bad news.
As I wrote, I took into consideration that you don't want to code it yourself. That's why I recommended to open up an interface to let somebody else do it.
On the other hand I can understand also that you want to be restrictive with interfaces - a dilemma!
Here open source development would have a small advantage.
As VPS is embedded in Teletext I think it could be a general Teletext interface. Or are you not implementing Teletext for NPVR altogether?
I'm not sure if the fact that it was nearly never mentioned also means that nobody would be interested in it.
And even if analog is dying I probably will be using it for some years to come. Digital has some advantages over analog but they don't outweigh the controle that stations and the cable tv provider begin to exercise on consumers by the digital possibilities.

As good as GB-PVR is - and that's very promising for NPVR! -, the missing VPS feature let's me still look around for a different PVR, mainly on Linux.
Anyhow, I want to congratulate you on and thank you for your high quality software.

[sub]

Hm. That's exactly what I meant - except that I have an analog tuner.
Does it work for that also - assuming, that you abstracted this in a similar way as you abstracted the file format with the .ts files for both tuner types?
... well, I just sheduled a test...
Later: Ou, if my test is correct, it doesn't work for the analog tuner.

Sorry, this feature is only available to digital tuners.

I wont say I'll never implement it with analog, but I cant see it happening in the near future - too many other higher priority things on the to-do list.

Will it also be possible to have two overlapping manual recordings (on one tuner)?

Yes, but again that'll be only a digital only feature (since the digital subsystem already allows for it). Analog will not support overlapping recordings.

And that's bad news.
As I wrote, I took into consideration that you don't want to code it yourself. That's why I recommended to open up an interface to let somebody else do it.
On the other hand I can understand also that you want to be restrictive with interfaces - a dilemma!
Here open source development would have a small advantage.
As VPS is embedded in Teletext I think it could be a general Teletext interface. Or are you not implementing Teletext for NPVR altogether?
I'm not sure if the fact that it was nearly never mentioned also means that nobody would be interested in it.
And even if analog is dying I probably will be using it for some years to come. Digital has some advantages over analog but they don't outweigh the controle that stations and the cable tv provider begin to exercise on consumers by the digital possibilities.

As good as GB-PVR is - and that's very promising for NPVR! -, the missing VPS feature let's me still look around for a different PVR, mainly on Linux.

Hopefully NPVR will meet your needs. If not, and you require features like VPS and open source, and need to look at other PVR options, I can accept that. This is a one man project, and accept I cant meet everyone's needs. I've tried to write a flexible application, which gives the main features that people are asking for, but its hard to find available time for these less common sorts of requests, particularly when they require significant time and effort.

[next]

Hopefully NPVR will meet your needs. If not, and you require features like VPS and open source, and need to look at other PVR options, I can accept that. This is a one man project, and accept I cant meet everyone's needs. I've tried to write a flexible application, which gives the main features that people are asking for, but its hard to find available time for these less common sorts of requests, particularly when they require significant time and effort.

I certainly will keep an eye on NPVR or even use it as my main PVR.
I admire your project - your dedication, the outcome -, and I find your support very helpful.
Thank you!