Server Version#: 1.19.4.2854
Player Version#: N/A
Tuner Make/Model: HDHR Extend
Guide/Lineup name: N/A
Using XMLTV?: No
Channel number/Name: N/A
I upgraded to 1.19.4.2854 and have completed three test recordings. All were successful, but in addition to the normal .ts files, two additional files per recording were put in the show’s final destination directory:
A .log file with the same name as the .ts except for the extension. e.g. “ShowName - S01E01.log”.
A “segment-list.txt” file is also left in the directory for the first time a series episode was recorded, and subsequently a segment-list (copy 1).txt, etc.
It does not appear to be causing any issues, and I manually delete the .ts files when watched so I can delete these additional files. BUT… Is this intentional?
I don’t have verbose logging enabled - it produces too much in the log files, and honestly makes it harder for me to find problems!
FYI, below is the extract of the assimilator moving the files to the final destination directory. I will PM the full log file zip to you if it is helpful.
May 26, 2020 16:32:59.600 [0x7fa9235fb700] DEBUG - Assimilator: Postprocessing, we're going to put `First at Four - First at Four` in `/data/media/TV Shows/First at Four (2018)/Season 2020/First at Four (2018) - 2020-05-26 16 00 00 - First at Four.ts`
May 26, 2020 16:32:59.600 [0x7fa9235fb700] DEBUG - Assimilator: Moving "/data/media/TV Shows/.grab/2dd51fd5dbbad622c90ab91cc969862e90bbc4dc-4082d55c2406fbe7aed4df38c3a8a6c1e285926c/First at Four (2018) - 2020-05-26 16 00 00 - First at Four.ts" to "/data/media/TV Shows/First at Four (2018)/Season 2020/First at Four (2018) - 2020-05-26 16 00 00 - First at Four.ts"
May 26, 2020 16:32:59.600 [0x7fa9235fb700] DEBUG - Assimilator: Moving "/data/media/TV Shows/.grab/2dd51fd5dbbad622c90ab91cc969862e90bbc4dc-4082d55c2406fbe7aed4df38c3a8a6c1e285926c/segment-list.txt" to "/data/media/TV Shows/First at Four (2018)/Season 2020/segment-list.txt"
May 26, 2020 16:32:59.600 [0x7fa9235fb700] DEBUG - Assimilator: Moving "/data/media/TV Shows/.grab/2dd51fd5dbbad622c90ab91cc969862e90bbc4dc-4082d55c2406fbe7aed4df38c3a8a6c1e285926c/First at Four (2018) - 2020-05-26 16 00 00 - First at Four.log" to "/data/media/TV Shows/First at Four (2018)/Season 2020/First at Four (2018) - 2020-05-26 16 00 00 - First at Four.log"
Actually I think I might be wrong lt me confirm, but it seems they are now also present if errors occur, but I I’m not sure this was the intent, I’ll double check.
Do post the PMS logs though, we should confirm if an error did occur, if not, then we would have a bigger bug, even if its a bit harmless (A part form wasting disk space)
Thank you! FYI, just to close the testing loop, I rolled back to 1.19.3.2831. I’ve done one test recording since the rollback, and I didn’t get the extra .log and .txt files.
In all cases, both before and after the rollback, the commercial skipper did its job and the recordings were successful. If I didn’t do manual file deletes I wouldn’t have noticed anything.
Yes the fact that we log it is intentional and so is keeping those on error or VERBOSE to help track those issues. However it shouldn’t be happening on success (unless VERBOSE logging is enabled).
I upgraded to 1.19.4.2893 and have run a couple test recordings. I’m no longer getting the .txt files, but I am still getting the .log file per recording. I can PM debug level logs if you need.
