[mythtv] fixes to mythburn.py

T.Brackertz at gmx.net T.Brackertz at gmx.net
Tue Sep 27 14:08:02 UTC 2011


as I had trouble with bugs in mytharchive I fixed a couple of bugs.

Now I want to contribute the fixes but I'm not sure if I should open several tickets or only one ticket.

(It's the first time I get involved in the development of mythtv and I couldn't find an answer in the FAQs and I found many tickets with patches solving many bugs at once.)

Below there is a description of the changes.

So what's the next step to do?

Thanks, Stefan

Patches in mythburn.py

all irrelevant

Medium handling:
former issues:
- no possibility to cancel process
- one has to be fast enough feeding the device, otherwise the process cancels
- some devices need more time to close the tray. They get hard-resetted all the time. No chance to burn a disk, if it is not put in before the script is started
- if you use a disk of wrong type you don't get a chance to put in a correct one. The whole process cancels

changes in BurnDVDISO()

Integration of project-x
until now:
After the run of project-x its logfile is parsed (in renameProjectXFiles()) to find out the filenames of the files produced by project-x and to associate them to the streams

- not very reliable: in many constellations (e.g. recoded .flv-videos) the logfile doesn't fit the expectations. Although there is a fallback mechanism in many cases the script crashes while parsing before reaching the fallback
- the format of the logfile seems to change often if there is a new version of project-x. The parser has to be renewd all the time. (the recent one works for project-x 0.91 but not for older ones)

- An 0.91 project-x learned a new command line option (-set ExternPanel.appendPidToFileName=1) which causes project-x to use filenames for the output containing the PIDs and SubPIDs in a predictable manner. This should work with upcoming versions, too.
- Therefore no more parsing is necessary.
- Nevertheless there is still a fallback mechanism as in some cases (e.g. recoded mggs) mytharchivehelper gives strange IDs which makes it impossible to find the wanted files by ID
- As the current parser relies on project-x 0.91 as well there is no regression by the fact that at least version 0.91 is necessary now. (The version dependency at the beginning of the sript claiming for project-x 0.90.4 was outdated anyway.)

changes in runProjectX(), renameProjectXFiles() is obsolete now

Divide-by-zero-error when requantising

If M2VRequantiser fails for some reason (probably it is not installed) the script crashes with a missleading error message.

The exit-code of M2VRequantiser is evaluated too late: After then run the size of the produced file is evaluated which gives a divide-by-zero-error. The exit-code of M2VRequantiser is evaluated thereafter, which means never because the script crashes before.

change the order

changes in runM2VRequantiser

Misleading log-entry
The log-entry produced by getStreamInformation() sometimes mentions the wrong file as the filename is hard-coded

use the appropriate variable

changes in getStreamInformation()

Inconsistent string-handling in the whole script
many errors and crashs when sript is used with recordings having special characters in their title or videos with special chars in the filename.

One part of the strings is unicode (mainly coming from parsing the xml-files), another part is utf-8-encoded (mainly coming from database). They get mixed up and / or get printed to logfile or console unencoded or double-encoded. This results in many errors.

Consequently use unicode-strings:
- make the database-object use unicode-strings in getDatabaseConnection()
- encode strings to utf-8 before printing to logfile or console in write() and runCommand()
- remove all encode- and decode-statements in the rest of the script

Endless growing work-directory
In some rare cases in which many DVDs with many small and one big title are created the work-directory theoreticallly grows endless

Before a new file is written to disk the old file with the same name is deleted but the rest is not.
Imagine the following situation:
Create a DL-disc with 20 titles, all very small, only the last one having 8GB. You get 20 subdirs in the work-directory of which the "20"-directory is very big. All together they have 9GB.
Next step: The same as before but with only 19 titles. Result: Only the first 19 dirs of the last run get deleted, the big "20"-dir stays. But there is a new big "19"-dir. All together they have ~17GB
An so on. You end up with a work directory containing at least 160GB

delete everything in the "work"-dir at the beginning instead of incrementally deletion. Also shortens the code.

new deleteEverythingInFolder()-function and changes at some other places
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

More information about the mythtv-dev mailing list