Beets crashes with audioread.ffdec.ReadTimeoutError

[GoogleCodeExporter]

What's the problem? How can I reproduce it?
Tried running an interactive import of my music library, after letting it run 
for several hours and answering some questions now and then beets died:

/pool/beets_unscanned/At the Gates - Outgivet
Finding tags for album "At the Gates - Outgivet".
Candidates:
1. At the Gates - Terminal Spirit Disease [1994] (48.0%)
2. At the Gates - Terminal Spirit Disease [Peaceville Records, 1994] (48.0%)
3. At the Gates - Terminal Spirit Disease [1994] (48.0%)
4. At the Gates - Terminal Spirit Disease [1994] (48.0%)
5. At the Gates - Slaughter of the Soul [Earache Records, 1995] (43.4%) 
(partial match!)
# selection (default 1), Skip, Use as-is, as Tracks, Enter search,
enter Id, aBort? s
Traceback (most recent call last):
  File "/usr/local/bin/beet", line 9, in <module>
    load_entry_point('beets==1.0b13', 'console_scripts', 'beet')()
  File "/usr/local/lib/python2.6/dist-packages/beets/ui/__init__.py", line 725, in main
    subcommand.func(lib, config, suboptions, subargs)
  File "/usr/local/lib/python2.6/dist-packages/beets/ui/commands.py", line 740, in import_func
    timid, query, incremental, ignore)
  File "/usr/local/lib/python2.6/dist-packages/beets/ui/commands.py", line 638, in import_files
    ignore = ignore,
  File "/usr/local/lib/python2.6/dist-packages/beets/importer.py", line 835, in run_import
    pl.run_parallel(QUEUE_SIZE)
  File "/usr/local/lib/python2.6/dist-packages/beets/util/pipeline.py", line 242, in run
    out = self.coro.send(msg)
  File "/usr/local/lib/python2.6/dist-packages/beets/importer.py", line 536, in initial_lookup
    task.set_match(*autotag.tag_album(task.items, config.timid))
  File "/usr/local/lib/python2.6/dist-packages/beets/autotag/match.py", line 445, in tag_album
    va_likely)
  File "/usr/local/lib/python2.6/dist-packages/beets/autotag/hooks.py", line 114, in _album_candidates
    out.extend(plugins.candidates(items))
  File "/usr/local/lib/python2.6/dist-packages/beets/plugins.py", line 228, in candidates
    out.extend(plugin.candidates(items))
  File "/usr/local/lib/python2.6/dist-packages/beetsplug/chroma.py", line 114, in candidates
    for relid in _all_releases(items):
  File "/usr/local/lib/python2.6/dist-packages/beetsplug/chroma.py", line 87, in _all_releases
    aidata = acoustid_match(item.path)
  File "/usr/local/lib/python2.6/dist-packages/beetsplug/chroma.py", line 42, in __call__
    res = self.func(*args, **kwargs)
  File "/usr/local/lib/python2.6/dist-packages/beetsplug/chroma.py", line 54, in acoustid_match
    parse=False)
  File "/usr/local/lib/python2.6/dist-packages/acoustid.py", line 277, in match
    duration, fp = _fingerprint_file_audioread(path)
  File "/usr/local/lib/python2.6/dist-packages/acoustid.py", line 237, in _fingerprint_file_audioread
    fp = fingerprint(f.samplerate, f.channels, iter(f))
  File "/usr/local/lib/python2.6/dist-packages/acoustid.py", line 181, in fingerprint
    for block in pcmiter:
  File "/usr/local/lib/python2.6/dist-packages/audioread/ffdec.py", line 88, in read_data
    raise ReadTimeoutError()
audioread.ffdec.ReadTimeoutError

Not sure how exactly to reproduce this as I'm unsure which file is causing this 
issue.

Original issue reported on code.google.com by akegata@gmail.com on 24 Mar 2012 at 7:14

[GoogleCodeExporter]

Awesome. Again, my apologies that this ffmpeg backend turned out to be much 
less mature than I originally thought. Unexpected variations in the way the 
FFmpeg CLI behaves can cause weird problems like this.

To begin fixing this, can you help narrow this down to the file that's causing 
the crash? The best way to do this is probably to disable threading (put 
"threading: no" in ~/.beetsconfig) and import a few suspect albums in verbose 
mode ("beet -v import ..."). This way, you'll see exactly which file is being 
fingerprinted at the time of the crash.

Original comment by adrian.sampson on 26 Mar 2012 at 6:39

[GoogleCodeExporter]

Well this is annoying. I've tried to import some stuff now, and it's crashed 
twice on two different places. I can't consistently reproduce this problem. :/

Original comment by akegata@gmail.com on 29 Mar 2012 at 5:29

[GoogleCodeExporter]

Argh; that's frustrating. I just pushed two new changes to audioread that (a) 
might make the timeout more robust and (b) will dump out FFmpeg's stderr output 
if a timeout occurs. This way, we should be able to see what's going wrong in 
the FFmpeg CLI utility to cause this.

Original comment by adrian.sampson on 29 Mar 2012 at 8:12

[GoogleCodeExporter]

Alright, that sounds good. I'll try it out when I have some time.
With that version I wouldn't have to use the -v flag, right? It makes the whole 
import process very messy. :P

Original comment by akegata@gmail.com on 29 Mar 2012 at 8:40

[GoogleCodeExporter]

Nope, -v isn't required to get that output. Here's hoping.

Original comment by adrian.sampson on 29 Mar 2012 at 8:54

[GoogleCodeExporter]

Thought I should give this a try now, but I'm a bit confused about getting the 
latest version of audioread. Downloading the zip from github gives me 
sampsyo-audioread-0.5-4-g16e1deb.zip, but the change log says 0.6 is the 
version with this fix.

Original comment by akegata@gmail.com on 4 Apr 2012 at 8:31

[GoogleCodeExporter]

I'm pretty sure that's the latest version -- I think 0.5 shows up in the 
filename because it's the most recent tag (I haven't tagged & released 0.6 
yet). I think the 4 in there means that the tarball is 4 commits ahead of the 
tag (and 16e1deb is the hash of the most recent commit).

Original comment by adrian.sampson on 5 Apr 2012 at 3:22

[GoogleCodeExporter]

Any news on this? Did the latest versions of audioread clear this up?

I'll close this ticket for now but we can reopen if the problem persists.

Original comment by adrian.sampson on 20 May 2012 at 6:45

• Changed state: Fixed