Add / Remove Content: dynamic recalculation of timing is incorrect
  • Vote Up0Vote Down pacijapacija
    Posts: 17Member
    Hi,

    I have a few dynamic smart blocks generated by reading genre field in tag. I also have playlists into which those smart blocks are inserted. Next, I am filling shows with those playlists (add / remove content in calendar), so I see tracks and their timings in right panel. Finally, I am adding jingle manually so it plays after every track that finishes after Xh00min, or Xh30min. Jingle duration is 6.3, as seen by airtime library, and I am using 5s default crossfade.

    So, after I drag'n'drop playlist to show pane at the right, track starts and ends are calculated, I guess correctly. The problem is that manual adding of the jingle does not recalculate timing of remaining tracks correctly (push them a few seconds further). Only after clicking "Ok", and reopening show, times get re-calculated. In practice this means that - if I want to have timings of jingles as I wish, I need to add jingle, click "Ok" so it recalculates remaining tracks, open "add / remove" content again, add another jingle, click "Ok" for recalculation, rinse, repeat. If I add them all in one session, the first one has timing correct, but remaining ones do not.

    Perhaps I am doing all this wrong, in which case I would be grateful for instruction on how to do it correctly. In the meantime, until notorious request for automatic jingles without hacking liquidsoap script is fulfilled, is it possible to make recalculation work correctly?

    Thank you in advance,
  • 6 Comments sorted by
  • Vote Up0Vote Down pacijapacija
    Posts: 17Member
    Actually, things are a little different than I described. It appears that timings remain incorrect even after clicking "Ok".

    The first screenshot shows timings before I add jingle. Timings appear to be correct. First track starts at 18:00, has duration of 2:51.2, so it ends at 18:02:51. Second track starts at 18:02:46 (5s earlier than the previous one ends, thus correctly crossfaded), has duration of 4:06.0, so it ends correctly at 18:06:52.
    image

    Now, after I put jingle as a first track in the list, times are not correct. Jingle starts at 18:00, has duration of 6.3, so it ends correctly at 18:00:06. Next track starts correctly at 18:00:01, has duration of 2:51.2, which means it should end at 18:02:52, but it doesn't - it ends at 18:02:47. The next one starts relatively correct - 5s before the previous track ends (let's put aside for a moment the fact that the first one did not finish at correct time), has duration of 4:06.0, which means it should end at 18:06:48, but it doesn't - it ends at 18:06:43 instead.
    image

    It appears that adding the same jingle later on again in same show does not increase duration of error. As far as I tested, it appears that all consequent songs get last 5 seconds chopped.

    Hope developers will know what to do with this feedback. If there is anything I can do from my side (additional testing, logs etc.) I'd be more than willing to participate.

    Regards,
  • Vote Up0Vote Down pacijapacija
    Posts: 17Member
    I did some more testing, and found a workaround. The trick is to create slightly longer smart blocks than shows (e.g. 5hrs block for 4hrs show). After cutting overlapping tracks and adding jingles (resulting in incorrect timings), switching order of last and second-to-last track appear to correct all the timings. After that, I can achieve perfect timing (0s) by sorting tracks of appropriate genre in left pane (library) by duration, removing of the last track from the playlist (the one that is a bit short, or overlaps a bit), and replace it by the one with duration that fits perfectly.

    Hopefully this will be helpful to users, but also to developers to investigate why this bug happens.
    Post edited by pacija at 2014-12-08 15:28:01
  • Vote Up0Vote Down Roger WilcoRoger Wilco
    Posts: 784Banned
    Are your ingested files all the same codec and quality? Are you using CBR or VBR?
  • Vote Up0Vote Down pacijapacija
    Posts: 17Member

    Roger Wilco said:

    Are your ingested files all the same codec and quality? Are you using CBR or VBR?



    They most certainly aren't - all of them differ by means of codec, quality and bitrate.

    I noticed that airtime has a lot less problems with CBR, and at one point I was seriously considering re-encoding my complete collection to 128Kbit/s CBR (as my radio streams in 128k). Not only would I have less problems with airtime, I could also reduce storage requirements. However, re-encoding strips all the tags from the tracks, and it would be to much of an effort to re-tag them all.
  • Vote Up0Vote Down Ade HillAde Hill
    Posts: 73Member
    Yeah Airtime doesn't deal with VBR very well at all.
    It will miscalculate the file length of VBR files 99% of the time.
  • Vote Up0Vote Down Ade HillAde Hill
    Posts: 73Member
    By the way, I don't think re-encoding all your files has to strip all of the the tags.
    I'm sure (but not 100% positive) that you can re-encode with EyeD3 specifying which tags to change.

    http://eyed3.nicfit.net

    I have it set up so every time a new file is added to the database it does it's magic so I don't have to worry about naming files etc.
Add a Comment