synrg/asx2mp3 — Issue #3: Misnumbered tracks - unsafe thread operation?
Author: synrg
Created: 2011-11-20 11:55:57+00:00
State: open

The counter incremented in the main loop is not incremented within the threads, so it was thought to be thread-safe, yet in a recent run, it appears that what should have been track 12 was overwritten with 13.ogg, and that was a short write. This *looks* like a race (though I don't understand exactly how it could be).

Suggestion? Unthread the ruby code. Rationale:

Given that #1 also relates to threading, perhaps it's time to more seriously consider the xargs -P suggestion for ripping all of the mms streams at once and unthread the ruby code entirely. And in any case, in the state the code is in now, no new behaviours can be implemented that occur after the tracks are all ripped and tagged (such as cleanup of the tmpdir). Also, there is no real benefit to doing the ffmpeg jobs in parallel as they will all be competing with each other for resources. The downside of doing so is that each mms uri in the stream needs to have a unique filename not assigned by asx2mp3 itself. Fortunately, the CBC radio streams used in testing so far all meet this assumption (and since it's a reasonable requirement, just assume for now this always hold).

Furthermore, as indicated in #2, if the mplayer part of the pipeline is replaced with libmms, the code could be rewritten again to do the downloads in parallel in ruby, this time without the added complication of using system() in each thread, which does not work properly.