Opened 8 years ago
Closed 7 years ago
Last modified 7 years ago
#12845 closed Bug Report - General (fixed)
mythtranscode deleting original recording with -o option
Reported by: | Owned by: | JYA | |
---|---|---|---|
Priority: | blocker | Milestone: | 0.28.1 |
Component: | MythTV - Mythtranscode | Version: | 0.28.0 |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
In 0.27 I used the following procedure to process some OTA TV recordings I wanted to save on a NAS:
- using mythfrontend, I'd edit the recording using the detected commercial list and fix any issues and save the edited list to the cutlist.
- I'd run the command:
mythtranscode --chanid 1111 --starttime 20160805000000 --mpeg2 --honorcutlist -o new-output-file.mpg
- use handbrake to convert the .mpg file and put if on my NAS
Using this method I still had the original file within Mythtv.
In version 0.28 mythtranscode will create 'new-output-file.mpg' but it deletes the original and now mythfrontend can't find it and gets an error.
If I do not use the -o option it behaves correctly and mythfrontend finds the same program and plays it but the cutlist has been applied and deleted.
BTW, using the extension .ts instead of .mpg doesn't change the behavior.
I see nothing in the 0.28 information that says the intent of mythtranscode changed from 0.27 to 0.28.
Attachments (1)
Change History (23)
Changed 8 years ago by
Attachment: | transcode log for Hogans Hero.txt added |
---|
comment:1 Changed 8 years ago by
This has similarities with #12698
Perhaps https://www.mythtv.org/wiki/Copy_and_transcode.pl does what you want.
comment:2 Changed 8 years ago by
In 0.28 there is a tickbox in mythtv-setup / 1. General / Job Queue (global) about page 9 or so "save original files after transcoding". Do you have this box ticked / unticked and does it change the behaviour you see?
comment:3 Changed 8 years ago by
There was a good discussion in the mythtv-user mailing list.
http://lists.mythtv.org/pipermail/mythtv-users/2016-August/388219.html
comment:4 Changed 8 years ago by
Hi If someone uses mythtranscode on the command line or in script to transcode a recording its their business if they want to delete, or rename or what ever to the original recording, its meta data, its cut lists or anything else, it worked well for 10 years why mess with it. Related bugs are 12385, 12698 and maybe more. Multiple patch files have been submitted. Ever hoping this to be resolved after 2 years... Steve G.
comment:5 Changed 8 years ago by
I did some testing on this. I did a clean install of mythbuntu 14.04.4 and made sure the 0.27 respositories were enabled and updated to the latest versions of 0.27. On recorded TV I started with the commercials that were auto detected and then modified them manually and saved the cut list. I used the mythtranscode CLI with the -o option to get a mpeg2 version honoring the cut list. It worked as expected and the database was not touched. the original recording was still there with all cuts listed. The problems only happened when moving to 0.28.
comment:6 Changed 8 years ago by
So someone changed the behavior so that mythtranscode with -o ? How was that a good plan, given the number of scripts out there that rely on it. https://www.mythtv.org/wiki/Script_-_RemoveCommercials being just one of them) This change causes unexpected data loss of the original file. Please revert.
comment:7 Changed 8 years ago by
That change in behavior (of -o no longer working) is not noted in the release notes for .28 https://www.mythtv.org/wiki/Release_Notes_-_0.28
comment:9 Changed 8 years ago by
Milestone: | unknown → 0.28.1 |
---|
comment:10 Changed 8 years ago by
the 28.0 version of mythtranscode also deletes the input file when used to rebuild the keyframe index.. (I upgraded to 28.0 today) I've been this user job to reubild the keyframe index for years: /usr/bin/mythtranscode -b -i "%DIR%/%FILE%"
comment:12 Changed 8 years ago by
mythcommflag takes about 20 times longer to rebuild the keyframe index. Not what I want.
comment:13 Changed 8 years ago by
OK. I offered it as an available workaround because Tickets often don't give that. But for the pure --rebuild case I usually find that the elapsed time is mostly for disk i/o.
comment:14 Changed 7 years ago by
#12915 reports the deletion of recordings by MythArchive?... which is somewhat ironic. When mythburn.py is configured to use mythtranscode, in the creation of a dvd, it uses the --outfile option.
comment:15 Changed 7 years ago by
Priority: | major → blocker |
---|
comment:16 Changed 7 years ago by
This appears to be the change that caused this issue. https://code.mythtv.org/trac/browser/mythtv/mythtv/programs/mythtranscode/main.cpp?rev=3d64f8a90816fd611c50e1483f1580e3b0609cc9
Changed
if (jobID >= 0)
CompleteJob?(jobID, pginfo, useCutlist, &deleteMap, exitcode);
to
CompleteJob?(jobID, pginfo, useCutlist, &deleteMap, exitcode);
Am assuming most of the time when -o option is used mythtranscode has been run from the commandline and will have no jobID.
Note change https://code.mythtv.org/trac/browser/mythtv/mythtv/programs/mythtranscode/main.cpp?rev=0f52e5c146625aef83ca880974ce94efcd17c5fb[[BR]]
Changed it to
if (!cmdline.toBool("hls"))
CompleteJob?(jobID, pginfo, useCutlist, &deleteMap, exitcode);
Maybe could use same type of check for -o option rather than rely on no job id.
comment:17 Changed 7 years ago by
Update to previous comment. This has worked for me.
mythtv/programs/mythtranscode/main.cpp
from
if (!cmdline.toBool("hls"))
CompleteJob?(jobID, pginfo, useCutlist, &deleteMap, exitcode, result);
to
if (!cmdline.toBool("outputfile") && !cmdline.toBool("hls"))
CompleteJob?(jobID, pginfo, useCutlist, &deleteMap, exitcode, result);
comment:18 Changed 7 years ago by
See ticket https://code.mythtv.org/trac/ticket/12385 Also need !cmdline.toBool("fifodir")
And ticket https://code.mythtv.org/trac/ticket/12915 seems to be caused by this same issue.
comment:19 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
console log of mythtranscode issue