Airtime 2.1.3 Now Playing gets out of sync with actual Icecast2 stream
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    As shows play the Airtime Now Playing gets further behind the actual Icecast2 stream a few seconds at first but after an hour it's several minutes behind..  Airtime and Icecast2 are running on the same server.  Use another computer with Winamp to listen to vorbis/ogg stream.  Use that same computer to login to airtime using FIrefox 14.  After a while of operation the next song will start playing in Winamp 10 seconds to 5 minutes before the same song starts playing in airtime's Now Playing in Firefox.  Have re-booted server and everything starts up, now playing is within a couple of seconds ahead of actual stream for a while, then slowly lags further and further behind as songs play.

    Server is running Ubuntu 12.04 with all latest updates on Dell 4 CPU processor (see attached airtime-check-system output file).
    I've also attached the pypo.log and ls_script.log files.  I am new to using airtime.
  • 9 Comments sorted by
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    Update - the Now Playing doesn't always lag behind the Icecast2 stream - sometimes it gets ahead - right now it is 3:14 minutes ahead.  Airtime has been running about 3 hrs. 15 min.  The log files attached to the initial message were captured about 10 minutes after the server booted so they show the airtime startup.
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    Ahh, this might help - while listening, song abruptly ended, next song was skipped, and play began with the song after it - now playing and Icecast2 now in sync.  Attached is the last 25 minutes of the ls_script.log file. By the way, the music library is on a local hard drive.  There are no missing mp3 files, nor were any files moved or edited.
    ls_script2.log
    10K
  • Vote Up0Vote Down Martin KonecnyMartin Konecny
    Posts: 1,860Member
    "while listening, song abruptly ended, next song was skipped"
    "There are no missing mp3 files, nor were any files moved or edited."

    I'm confused because those two statements seem to contradict each other. 

    BTW, at the moment Airtime has a very optimistic view of track scheduling. It expects them to finish exactly when they promised they would although this is obviously not always the case. We have a better method of approaching this, and will be defn fixing it in a future release.
    Airtime Pro Hosting: http://airtime.pro
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    Sorry for the confusion - what I meant is that no files were deleted from the library or edited by me while the station was running.  There is at least one entry in the ls_script.log indicating a song couldn't be found (in the pypo cache, I think).  I'm very new to using airtime.

    While monitoring today, I discovered that in one instance the metadata read by Airtime for a song is very wrong.  It indicated that a song's duration was 18:53 when in fact it is 3:22.  I am investigating that mp3 file with other programs (Adobe Audition, Tag&Rename, Audacity).  From your comment, I gather that if the song's duration in the mp3 tag is wrong, that bad things will happen during a show.  From looking at the
    ls_script.log I take it that "[cue_cut_5160:30] Cueing out..." is the proper entry when a song finishes playing properly.

    Does anyone know of a batch tool which will examine mp3 tags and report any duration discrepancies?  I've collected a large number of mp3 files from different sources over the years so it's quite possible there are some errors.
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    What does the following excerpt from the ls_script.log mean?  I appreciate your help as I'm learning.

    ls_script-excerpt.log
    1K
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    Found mp3check and mp3info commands which do some error checking, but these commands only use id3v1 tags at the end of the mp3 file.  I really need to check the id3v2 tags at the beginning of the mp3 files.
    I will keep looking - Google searches produce lots of output!
  • Vote Up0Vote Down Martin KonecnyMartin Konecny
    Posts: 1,860Member
    The ls_script.log looks fine.

     It indicated that a song's duration was 18:53 when in fact it is 3:22.  I am investigating that mp3 file with other programs (Adobe Audition, Tag&Rename, Audacity).  

    Would you mind sending me a link to that song as a private message? I could investigate what's going on and possibly file a bug with the file tag reader.
    Airtime Pro Hosting: http://airtime.pro
  • Vote Up0Vote Down Jack FolchiJack Folchi
    Posts: 13Member
    Good morning - Thank you very much for responding.  I was up until 2AM after finding the EasyTag and mp3diags programs.  EasyTag displayed the incorrect duration of 18:53 for the song.  mp3diags reported "The MPEG audio stream uses VBR but a Xing header wasn't found.  This will confuse some players which won't be able to display the song duration or to seek."  mp3diags did a "Rebuild VBR data" which removed any VBRI and Xing headers and created a new Xing header.  I checked the file with EasyTag and it now displayed the correct duration. I put the "fixed" song in a show this morning and airtime now sees the correct duration of 3:22.  It sounded fine and Airtime "Now Playing" remained in sync (a few seconds ahead like I expected) with Icecast stream.  The ls_script.log now has "Cueing out ..." instead of "End of track before cue-out point."  I will slowly go through my mp3 library and clean them up.  Would you still like the original song with the bad header?  Thank you again!
  • Vote Up0Vote Down Martin KonecnyMartin Konecny
    Posts: 1,860Member
    If it's an issue with a corrupted track then it is not necessary to send it over. Glad to hear you fixed the issue :). 
    Airtime Pro Hosting: http://airtime.pro
Add a Comment