DeleteAdditionalExtensions

[dsreyn]

I want to have the ability to share my NextPVR recordings with JRiver Media Center.  So, I set up a PostProcessing hook (so PostProcessing.sh and a corresponding Awk script) to create a JRiver "sidecar" file from the NextPVR .xml file.  I had my first test of this yesterday, and everything seemed to work fine.  After my recording was completed, I had three files:

/recordings/Bruins/NHL Hockey_20200208_15001730.ts
/recordings/Bruins/NHL Hockey_20200208_15001730.xml
/recordings/Bruins/NHL Hockey_20200208_15001730_ts_JRSidecar.xml

So far, so good.  I also want to get rid of the sidecar file when I delete the recording, so I added "_ts_JRSidecar.xml" to the DeleteAdditionalExtensions entry in config.xml.  So that is now:

<DeleteAdditionalExtensions>srt,txt,log,d2a,edl,csv,bat,wme,vprj,logo.txt,dvbsub,sm,xml,map,_ts_JRSidecar.xml</DeleteAdditionalExtensions>

However, when I deleted the recording last night (and to be clear, I deleted it from NextPVR - NOT using JRiver), the _ts_JRSidecar.xml file stayed behind.  Here's what I see in the log file:

2020-02-09 00:51:05.875 [DEBUG][89] Got request [::ffff:192.168.1.198]: /services/service
2020-02-09 00:51:05.879 [DEBUG][89] method=recording.delete
2020-02-09 00:51:05.879 [DEBUG][89] parameters:
2020-02-09 00:51:05.879 [DEBUG][89]   method: recording.delete
2020-02-09 00:51:05.879 [DEBUG][89]   recording_id: 2472
2020-02-09 00:51:05.879 [DEBUG][89]   format: json
2020-02-09 00:51:05.879 [DEBUG][89]   sid: 660f6b7b-f06b-4717-94c5-ebde359bf62a
2020-02-09 00:51:05.879 [DEBUG][89]   client_ip: ::ffff:192.168.1.198
2020-02-09 00:51:05.879 [DEBUG][89]   user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
2020-02-09 00:51:05.879 [DEBUG][89]   host_callback: doug-nas:8866
2020-02-09 00:51:05.879 [DEBUG][89] DeleteRecording
2020-02-09 00:51:05.880 [DEBUG][89] Requesting deletion of (2472): /recordings/Bruins/NHL Hockey_20200208_15001730.ts
2020-02-09 00:51:05.880 [DEBUG][89] DeleteRecording(2472)
2020-02-09 00:51:05.881 [DEBUG][89] DeleteRecording@1
2020-02-09 00:51:05.881 [DEBUG][89] PowerManagement CancelWakeup (needs implementation)
2020-02-09 00:51:05.881 [DEBUG][89] -removing: /recordings/Bruins/NHL Hockey_20200208_15001730.ts
2020-02-09 00:51:06.976 [DEBUG][89] DeleteRecording@2
2020-02-09 00:51:06.977 [DEBUG][89] -removing: /recordings/Bruins/NHL Hockey_20200208_15001730.xml
2020-02-09 00:51:06.978 [DEBUG][89] PlaybackPositionHelper.DeletePlaybackPosition(/recordings/Bruins/NHL Hockey_20200208_15001730.ts)
2020-02-09 00:51:07.195 [DEBUG][89] DeleteRecording@5
2020-02-09 00:51:07.195 [DEBUG][89] DeleteRecording@exit
2020-02-09 00:51:07.195 [DEBUG][89] {"stat":"ok"}


So it looks like it didn't make any attempt to delete the sidecar file.  I can't tell if it completely ignored the DeleteAdditionalExtensions entry, or if it just didn't find a match between the rule and my sidecar file.
Is the problem that there's no "." in the filename immediately before "_ts_JRSidecar.xml"?  Or could my extension be too long for NextPVR to handle?

Thanks,
Doug

[mvallevand]

Yes that is the right part of a filename not the extension.

Martin

[sub]

Is the problem that there's no "." in the filename immediately before "_ts_JRSidecar.xml"?

Yes. As Martin said, unfortunately this is a change to the file name, rather than just the extension.

[dsreyn]

That’s what I suspected. I assume there’s no straightforward solution for this...there’s no “hook” (other actions to take when a file is removed), right? I should be able to set up a nightly job (separate from NextPVR) to look for orphans in the recordings hierarchy...shouldn’t be too difficult to do.

Doug

[sub]

I assume there’s no straightforward solution for this...there’s no “hook” (other actions to take when a file is removed), right? 

Sorry, no - there isn't at this stage.

[mvallevand]

A bigger question is why isn't it being deleted with the xml extension? I am guess it is a file permission thing and NextPVR isn't even seeing the file.

Could you use ._ts_JRSidecar.xml as the sidebar name to make it match?

Martin

[BrettB]

A bigger question is why isn't it being deleted with the xml extension?  I am guess it is a file permission thing and NextPVR isn't even seeing the file.

Because the file name isn't "/recordings/Bruins/NHL Hockey_20200208_15001730.xml". Well, that one is being deleted, I believe.

I'm pretty sure the "<DeleteAdditionalExtensions>srt,txt,log,d2a,edl,csv,bat,wme,vprj,logo.txt,dvbsub,sm,xml,map,_ts_JRSidecar.xml</DeleteAdditionalExtensions>" will only cause NextPVR to try to delete files with the same base name as the recording file (/recordings/Bruins/NHL Hockey_20200208_15001730 in this case) and those .extensions (i.e. "/recordings/Bruins/NHL Hockey_20200208_15001730.srt", "/recordings/Bruins/NHL Hockey_20200208_15001730.txt", "/recordings/Bruins/NHL Hockey_20200208_15001730.log", etc.)

[dsreyn]

A bigger question is why isn't it being deleted with the xml extension?  I am guess it is a file permission thing and NextPVR isn't even seeing the file.

Could you use ._ts_JRSidecar.xml as the sidebar name to make it match?

Martin

That should solve the cleanup problem, but I’m pretty sure that JRiver is completely inflexible on the sidecar filename, so it probably won’t use it.  I can certainly give it a try later though to see if it will grab it anyway.

Doug

[mvallevand]

Sorry my explanation wasn't good. In Windows it is hard to create a . as last character of a filename but in linux which your are using it is easier not sure that will make a difference but it might help fake it

Martin