I'm in the middle of recording a BattleStar Gallactica marathon. And it renamed a 2 parter with a (2) onthe second part. Which is great! Thanks to KingArgyle and ZaDDaZ! Next time they run the Classic Series, I might try editing the database beforehand, so the old ones go to a different folder.
I think I spoke too soon. I think I found a bug in the rename process. On shows where it detects a dupe file name (Either due to a repeat, or a two parter) The show with the (2) doesn't show up in GBPVR Recordings. It isn't in the database either. Could it be that the (2) isn't being passed into the database, and gbpvr is deleting it since the file doesn't exist?
Quote:That is the version I am using. It is renaming great, but some are being removed from the database after rename.
I believe I know why this is happening. GBPVR periodically (quite often it seems) verifies that all the files it thinks it has currently recorded exist and if one is found to not exist, it deletes the RECORDING_SCHEDULE record for it. This is happening after the rename but before the update to the database. To fix this issue, I'm starting a transaction and doing the database update first, locking the record, then renaming the files and committing the transaction. This should block GBPVR from reading that record until the rename operation is complete. The corrected files are attached. Let me know if this still happens because this utility is quite useless if it does.
Quote:it works but I see some extra code at times like it's switch on then switch off.. South Park.0000000000, MR G V-Operation.
tipstir, is "South Park.0000000000, MR G V-Operation" the resulting renamed filename? If so, is that possibly the episode name in your PROGRAMME table? That's the only way I can see that happening.
I also added a new message when the file being asked to be renamed does not show up in the database at all. It also detects if the file has already been renamed and if it is, it doesn't do it again, causing a (2) file without a base file.
ZaDDaZ Wrote:I also added a new message when the file being asked to be renamed does not show up in the database at all. It also detects if the file has already been renamed and if it is, it doesn't do it again, causing a (2) file without a base file.
Enjoy
I downloaded it and installed it, I'll try and test it out today. I might make a fake .mpg with an upcoming name just to test it. Plus tonight they are running the final 3 BattleStar Gallacticas of the season I think twice each, and the last two are the same name. Sounds like a perfect test!
I don't understand fully your last statement, the one I quoted. Can you explain it again?
I hope that your latest trick works, becuase I really like this feature. Perhaps Sub would make it a built in option that you select from the config, it would save all of the mucking with the database. Hint Hint...
Oh, well, I guess I have to go and reschedule all of the dupe episodes I cleared out this morning.
BTW I noticed that 2 more renamed shows disappear from the database that weren't (2) shows. I think you are right that GBPVR itself is clearing them out.
Well last night it recorded 5 battlestar galacticas.
04/01/2005 09:00 PM 1,806,213,056 Colonial Day.mpg
04/01/2005 10:00 PM 1,805,952,960 Kobol's Last Gleaming.mpg
04/02/2005 12:00 AM 1,806,141,376 Colonial Day (2).mpg
04/02/2005 01:00 AM 1,805,615,040 Kobol's Last Gleaming (2).mpg
04/02/2005 02:00 AM 1,805,017,024 Kobol's Last Gleaming (3).mpg
As you can see the renaming/numbering worked perfect.
The times are the end times. In the GBPVR database, the one that ended at 10:00pm is missing.
Also, I noticed that in the "Videos" plugin, the shows don't show the (2) after them anymore. I was sure that they did before. Is it because that they are in the database and it is showing info from there instead of just the file name? (I bet that's it, that would be a good thing)
Do you think I should search the logs to see if GBPVR is removing it? I'll give it a shot.
I don't use Comskip and haven't had a problem with GBPVR deleting files, and I know it can take Comskip a while to run so the time delay may be causing some of the problems.
A couple of solutions:
1. Have RenameRecording kick of comskip after it has renamed the recording, and provide comskip with the new name. This would ensure that the file was updated in GBPVR as soon as possible, and thus eliminating any possible delay when it scans for the files.
2. Batch up your Comskips to run on a set of directories late at night. Have RenameRecording write to a file with the new names and have comskip use this file as it's input mechanism.
I definitely think it is the delay in comskip that could be causing the issues.
1. Have RenameRecording kick of comskip after it has renamed the recording, and provide comskip with the new name. This would ensure that the file was updated in GBPVR as soon as possible, and thus eliminating any possible delay when it scans for the files.QUOTE]
I'm all for this, but I don't think that is the problem. I wanted to do it that way before. I don't think remamerecording was having/causing this issue before. It might be the new version of it, or GBPVR? Plus I noticed that the archive plugin doesn't pick up the renamed shows. I want to disable the archive, but I don't know how to move the shows back.