Fixed? - PostProcessing - NScriptHelper.dll rename failed following 5.2.1 upgrade

[lostboy]

Hi I recently upgraded to 5.2.1 (from 5.1.1) and the last part of my PostProcessing.sh script (renaming the database record following a directory move) errored out (see extract).

I record shows to a /TV_temp directory (on SSD) and then use the PostProcessing.sh script to move them to spinning rust on /TV_Recordings.  

The simple fix was to change the database entry before moving the file, rather than after.  Is the change in behaviour a symptom of more active checking of the existence of recordings / database pruning than before, or has the rename behaviour in NScriptHelper.dll changed?

The error existed irrespective of the AutoRemoveMissingRecordings setting.

An example of the error I was seeing in the logs was:

2021-10-26 15:50:04.624 [DEBUG][66] Got request [127.0.0.1]: /services/service (recording.rename)

2021-10-26 15:50:04.625 [DEBUG][66] method=recording.rename
2021-10-26 15:50:04.625 [DEBUG][66] parameters:
2021-10-26 15:50:04.625 [DEBUG][66]   method: recording.rename
2021-10-26 15:50:04.625 [DEBUG][66]   from: /TV_temp/Escape to the Country/Season 22/Escape.to.the.Country.S22E07.Derbyshire.ts
2021-10-26 15:50:04.625 [DEBUG][66]   to: /TV_Recordings/Escape to the Country/Season 22/Escape.to.the.Country.S22E07.Derbyshire.ts
2021-10-26 15:50:04.625 [DEBUG][66]   sid: 8bca4e38b0a64fe59e4ce20421f9c5f6
2021-10-26 15:50:04.625 [DEBUG][66]   client_ip: 127.0.0.1
2021-10-26 15:50:04.625 [DEBUG][66]   host_callback: ...
2021-10-26 15:50:04.625 [DEBUG][66] Rename
2021-10-26 15:50:04.878 [ERROR][66] Unable to find existing recording with filename: /TV_temp/Escape to the Country/Season 22/Escape.to.the.Country.S22E07.Derbyshire.ts
2021-10-26 15:50:04.878 [DEBUG][66] <?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
  <err code="2" msg="Invalid Args" />
</rsp>

2021-10-26 15:50:04.886 [DEBUG][129] > rmdir: failed to remove directory '/TV_temp': Permission denied

[sub]

What is <AutoCreateFolders> folders set to in your config.xml?

[lostboy]

<AutoCreateFolders>true</AutoCreateFolders>

[sub]

I can't see anything obvious that has changed in the code, but maybe your script should copy the file, do the rename, then delete the original file.

[lostboy]

Good point - thanks sub,  I was using mv - I'll make the change and see how it goes.

Cheers

[mvallevand]

I think mv on the same file system is much better than copy and rename. Uploading the zipped logs showing the error would be beneficial,

Martin

[sub]

I think mv on the same file system is much better than copy and rename.  Uploading the zipped logs showing the error would be beneficial,

Martin

It basically comes down to <AutoRemoveMissingRecordings>. If he's moved it before the rename, then it sees it as missing when it loads the recording list to attempt to find the recording he's trying to move.

[mvallevand]

He posted " The error existed irrespective of the AutoRemoveMissingRecordings setting" In any case, could he rename it in the database and then do the mv it takes a long time to copy an hour recording. The call shouldn't require source and dest to exist.

Martin

[lostboy]

I've attached the logs covering the error in the OP - the extract was from nrecord.log.

Although the two directories appear to be on the same file system they are actually bind mounts to separate mounted zfs filesystems (on different pools) so both mv and cp will result in real data transfers.

I guess the appeal of a copy-DBrename-delete is that the database will always point to an existent file.

BTW I tested the copy speed and for an 11GByte ts file the cp command returned in just less than 25 seconds.  I guess that at that point the file is mostly in the cache RAM of the zfs pool, but it will be readable if needed.

Many thank both sub and Martin for your help.

[sub]

He posted " The error existed irrespective of the AutoRemoveMissingRecordings setting"    In any case, could he rename it in the database and then do the mv  it takes a long time to copy an hour recording.  The call shouldn't require source and dest to exist.

Martin

True - I missed that.