Opened 6 years ago
Closed 6 years ago
Last modified 6 years ago
#12291 closed Bug Report - General (fixed)
MythArchive needlessly copies "remote" Videos before processing
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | 0.28 |
Component: | MythTV - General | Version: | Master Head |
Severity: | medium | Keywords: | MythArchive Mythprotocol |
Cc: | Ticket locked: | no |
Description
I just created a DVD .iso that included Videos, which I had placed in mytharchive_work/ on a stand-alone laptop with a smallish disk. It worked, but started by copying the files into mytharchive_work/work/localcopy/
mytharchivehelper identifies a "remote" mythbackend by
if (filename.startsWith("myth://"))
return 3;
and I suspect this now means that *all* Videos will be copied in. Is there a better test?
Attachments (1)
Change History (10)
comment:2 Changed 6 years ago by
Replying to J.Pilk@…:
I believe I should be able to address this by relocating the test on copyremoteFiles==True in mythburn.py, but the query may have wider application.
I'm confused please explain what the problem is, what you changed and how does it fix it.
comment:3 Changed 6 years ago by
My attempts at changing mythburn.py to avoid the actual copying of a file that is already local didn't work. It looked as if I needed to translate myth://Videos@host/<path> to localpath, and I haven't found anything, in mythutils for example, to do that. StorageGroup? stuff again?
As I said, the image creation worked, but it uses more free disk space than is strictly essential.
comment:4 Changed 6 years ago by
A note, primarily addressed to me: there's code for this in mythcommflag --rebuild --video I don't know yet if it could be used or adapted.
mythtv-master/mythtv/programs/mythcommflag/main.cpp
comment:5 Changed 6 years ago by
John, I've attached a possible fix for this.
I can't test it since I don't have a combined FE/BE to test on.
comment:7 Changed 6 years ago by
Yes, that worked as intended. Many thanks. Of course, I can't test it on a multi-box system :-)
Patch applied to master v0.28-pre-2262-g5447a50
comment:8 Changed 6 years ago by
Owner: | set to Paul Harrison <pharrison@…> |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:9 Changed 6 years ago by
Milestone: | unknown → 0.28 |
---|
I believe I should be able to address this by relocating the test on copyremoteFiles==True in mythburn.py, but the query may have wider application.