Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12291 closed Bug Report - General (fixed)

MythArchive needlessly copies "remote" Videos before processing

Reported by: J.Pilk@… Owned by: Paul Harrison <pharrison@…>
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)

videoselector.diff (2.1 KB) - added by paulh 5 years ago.
possible fix (untested)

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 years ago by 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.

comment:2 in reply to:  1 Changed 5 years ago by paulh

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 5 years ago by J.Pilk@…

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 5 years ago by J.Pilk@…

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

Changed 5 years ago by paulh

Attachment: videoselector.diff added

possible fix (untested)

comment:5 Changed 5 years ago by paulh

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:6 Changed 5 years ago by J.Pilk@…

Thanks, Paul. I'll add it to my next build and report back.

comment:7 Changed 5 years ago by J.Pilk@…

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 5 years ago by Paul Harrison <pharrison@…>

Owner: set to Paul Harrison <pharrison@…>
Resolution: fixed
Status: newclosed

In e7230e19cc06da3a5cc50f9667f87520ac41bb38/mythtv:

MythArchive?: don't needlessly copy videos before processing

If a video can be found on the local file system pass that file name to the
mythburn.py rather than always passing a myth:// URL which will always cause
the script to do a file copy before processing the file.

Fixes #12291. Thanks to John Pilkington for testing.

comment:9 Changed 5 years ago by paulh

Milestone: unknown0.28
Note: See TracTickets for help on using tickets.