Liquidsoap

Audioscrobbler knocked out liquidsoap

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.0
  • Fix Version/s: 1.0.0-beta3
  • Component/s: ocaml-lastfm
  • Labels:
    None
  • Environment:
    Debian Squeeze

Description

I use Liquidsoap from SVN trunk, rev. 8219, with modules. After loading large mp3 file (~ 200 − 300mb = ~ 1h30m − 2h00m) to source and sent source to lastfm.nowplaying function with parameter length=true — Liquidsoap gets down. In Liquidsoap 0.9.3 length check works good. In the log falling info does not appear.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Romain Beauxis added a comment -
Hi,

I am not sure why it is working in 0.9.3 but I would clearly expect it to fail in this case.

The reason is that in the code your are using, if no "length" metadata is passed, mp3 length is computed by decoding the entire file, which is clearly too cost-intensive with such a file.

I can propose you two (in fact 3) alternatives:
 * Do not use the length option :)
 * Pass a "length" metadata. I have not read the code yet but I think I remember that in this case, the length is taken from this value and thus does not require computing the file's length
 * Try the current seek branch in our HG code. This branch has a support for computing mp3 length that should be much less cost-intensive. The changes in this branch should eventually make it into the default branch soon..
Show
Romain Beauxis added a comment - Hi, I am not sure why it is working in 0.9.3 but I would clearly expect it to fail in this case. The reason is that in the code your are using, if no "length" metadata is passed, mp3 length is computed by decoding the entire file, which is clearly too cost-intensive with such a file. I can propose you two (in fact 3) alternatives:  * Do not use the length option :)  * Pass a "length" metadata. I have not read the code yet but I think I remember that in this case, the length is taken from this value and thus does not require computing the file's length  * Try the current seek branch in our HG code. This branch has a support for computing mp3 length that should be much less cost-intensive. The changes in this branch should eventually make it into the default branch soon..
Hide
Permalink
Egor added a comment -
Thank you, Romain for answer. I tried to understand what happen and you was right — problem is in computing of length.
Show
Egor added a comment - Thank you, Romain for answer. I tried to understand what happen and you was right — problem is in computing of length.
Hide
Permalink
David Baelde added a comment -
Doesn't sound like a bug in the end, and it seems that the reporter is happy with proposed approaches.
Show
David Baelde added a comment - Doesn't sound like a bug in the end, and it seems that the reporter is happy with proposed approaches.
Hide
Permalink
Egor added a comment -
Unfortunately, I have not tried the next commits as recommended by Romain, so I rolled back to the stable version.
Show
Egor added a comment - Unfortunately, I have not tried the next commits as recommended by Romain, so I rolled back to the stable version.

People

  • Assignee:
    Romain Beauxis
    Reporter:
    Egor
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: