Importing recordings from linux VDR

[mvallevand]

If something fails I meant sending the zipped NextPVR logs.  Both folders did work in my testing but I now see there is an issue since NextTool was really designed for unique filenames so it only worked the first time running at the highest level  --vdr /srv/vdr/video/NextPVR/

I've added special handling for the --vdr option in this to allow duplicates.

Martin

[Nzbaxterman]

Great - that works and now picks up all the recordings.

Unfortunately when a VDR recording has multiple .ts files (when the recording is particularly long - like a movie) it's creating multiple entries in Nextpvr.

Attached is the log file.

I could 'cat' the 00001.ts and 00002.ts files together before running NextTool - but I'm sure you'd rather have something more elegant in the script. In VDR I've chosen to have relatively large files before VDR creates additional .ts files. But I'm sure others don't.

Thanks for all your help

[mvallevand]

Good I will put this on the Wiki. NextPVR doesn't have any notion of recordings that are split. That is why I noted that 00002 etc will be in the subtitle. When it is empty that will be the 00001.ts file

I don't plan on adding a cat feature since the user chose to split files on size likely because of filesystem limits (I can't see another good reason) so I have no idea if it will work.

If you do cat after the fact use a new filename. Kodi is very picky about duration so changing 00001.ts after the fact won't help, you'd need NextTool to recalculate the duration.

Martin

[Nzbaxterman]

A couple of more things which aren't quite 100% on this.

The imported recordings from VDR all have their payer resume set - often marked at the end of the recording (so marked as played) or sometimes about 80-90% of the way through, despite them not having been watched in VDR (or Kodi).

Is there a way to bulk-reset the resume play time? I've been looking in the Kodi API and it looks difficult to me.

Also, there's still the issue mentioned above where some recordings (which are over 1 hour, which I set in VDR, so have multiple .ts files in the directory) get added as multiple NextPVR recordings. I could get around this by "cat"ing the .ts files together in the directories before running NextTool, but is there something you could do in the dll? Sorry, I'm a linux guy and don't know enough about dotnet.


Thanks heaps!

[mvallevand]

Right I forgot about that, that's a bit of a bug in NextPVR design. Unfortunately the resume point is filename-only based and all these files are 00001.ts. It is not stored with the recording. It made sense in the old v4 network model, there was a time it did store the whole path, but changing it now will screw up everyone's resume points.

I suppose I could rename it but then you lose VDR playback. I could also create a symbolic link to a unique filename, but NextPVR won't delete the original unless you update config.xml to also delete 00001.ts and you could deal with manually deleting the additional segments.

I already posted that I wasn't going to cat the files for you. You choose one hour recordings which to me seemed like a bad idea from the start. I understand VDR was around before file systems supported 2GB files but this is a stupid limit now. I will see if I can create a script for you during the parsing.

Martin

[Nzbaxterman]

To be honest, I've had it recording 1 hour files since...forever. It's really not a problem. Appreciate what you've put together, it works like a charm. I can live with it.

It's also not much of a hassle to fix the resume point at a directory level, from the KODI interface. So that's not an issue for me now either.

[mvallevand]

I agree creating 1 hour segments is not a problem if you only want to use VDR. Many people like more flexibility.

Sub probably should revisit the resume issue for recordings for v6 though. I don't think it would take much to search the full path first, and save the full path for recordings. It would need to be rename it as part of the archiving. It could also fall back to searching to the filename only for the first resume point and then update it with the full path. For the Video Library it might need to not save the full path just because these aren't managed by NextPVR.

Martin

[Nzbaxterman]

Do you mean by searching the full path, you'd be looking to import the resume point for the existing file (as marked by VDR etc)?

i.e.
vdruser@ubuntu2020:~$ cat /srv/vdr/video/8~10_Cats_Does_Countdown/8_Out_Of_10_Cats_Does_Countdown/2021-03-19.20.33.3-0.rec/resume
I 13204
vdruser@ubuntu2020:~$

Personally I don't think this is necessary, as I'm just importing unwatched VDR files, but I could see how that could be useful. At a minimum they should be imported with no resume, or a resume at the first frame.

Simon

[mvallevand]

No I wasn't going to bother with the resume file, multi-segment files could be an issue. I was proposing that sub (the author of NextPVR) enhance resume to allow the same filename on different paths allowing different resume points.

Martin