Exported shows are allowed to be exported again

Bug #648451 reported by Steve Switzer on 2010-09-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mythexport (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: mythexport

The subject says it all. I selected a few shows for user job #2 in the myth web interface, and a show appeared in the RSS feed before I expected. So I performed a watch 'ls -l /mythexport-dir' and saw that the size was indeed still changing. My daughter downloaded the show to her ipod, but didn't get the whole thing. The order should be changed.

CORRECTION:
What would happen if I use OTG to export a file, then mistakenly select it AGAIN from within the myth web interface? This may have happened, and may have produced the illusion of a poorly ordered export. However, should mythexport notice this and refuse to export again?

Steve Switzer (steve-switzer) wrote :

Odd, the next show that was processed was not added before it was done - perhaps there was a unique situation here...

What would happen if I use OTG to export a file, then mistakenly select it AGAIN from within the myth web interface? This may have happened, and may have produced the illusion of a poorly ordered export. However, should mythexport notice this and refuse to export again?

summary: - Shows appear in the RSS feed before ffmpeg completes
+ Exported shows are allowed to be exported again
description: updated
rhpot1991 (rhpot1991) wrote :

I think this one is more of a feature request at this point in the release cycle. MythExport currently doesn't have any way of detecting if you have already exported a recording and part of this is to allow you to export recordings under different configs.

MarcRandolph (mrand) on 2010-09-27
Changed in mythexport (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
John Veness (pelago) wrote :

Being able to re-export the same program, for example after editing a config, is a useful feature and I would prefer to *not* see it blocked. But Steve's problem is a genuine one.

Usually the exported program is not added to the RSS feed until after the export is completed, and so an RSS client wouldn't download a half-exported program. In Steve's case, the problem was that, because he had already previously exported the program, it was already in his RSS feed, and when he set it to export again, it started overwriting the same file, and there is a few minutes window (depending on how long the export takes) when an RSS client could attempt to download the file in a half-finished state.

Regarding a solution, I wonder if a good fix would be to initially export the program to a temporary folder, or to the normal export folder but with a different filename, e.g. ending in ".tmp". Only when the program has completely finished exporting is the file moved to the normal export folder, or renamed to remove the .tmp, overwriting the previously-exported file if it exists. This would reduce the window when it was possible to download a half-exported program from a few minutes to just a few seconds.

John Veness (pelago) wrote :

Also, initially exporting to a temporary folder and only moving to the destination folder when fully exported, would have advantages not just for RSS users. For example, someone using an rsync client or some other method of syncing files from the normal export folder would be able to safely perform their folder sync operation at almost any time without having to worry that they might download partially-exported files. This would only work if exporting to a temp folder initially, not if exporting to the normal export folder but with a .tmp filename.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers