First of all thanks for the last update to PIL , it looks like your reconnection subroutine has really made a difference to the number of times we have lost streams in the last month. big reduction.
The issue. A couple of times recently we have had tracks skipped - hard clock - play track but the track doesn;t play and moves onto the next. If it's music track it's no issue, but it happened tonight with our 8pm podcast which people tune in for. (same thing happened a fortnight ago.
I've attached a screenshot - the file that was skipped was #48 Ian Waugh ... at 20:00 , should have played for 58 mins, but was skipped over. I have a couple of log files if any use.
Would appreciate any help and any pointers to how I might possibly read the logs for issues that it shows
Just to flag, we had this happen again on Sunday with our breakfast show programme, not broadcasting. The same thing happened where the fixed time marker loads up along with the show/file then nothing. The system skips over it and keeps playing random tunes.
The show was actually repeated on Monday lunchtime and it played fine so I am puzzled as to why for the most part things play and now we are seeing the odd bit of content (in our case at the moment entire programmes) being dropped and not played.
Any suggestions welcome :-)
We experienced the same issue on Sunday night where we had a fixed time marker (hard) for a programme going out at 9pm. It loaded in the log then didn't play, it skipped onto the playlist pattern and filled that hour with a random selection of tunes.
Just wondering if you identified what causes this and any possible workaround?
I am aware of this happening on one other occasion, probably a year ago but I put that down to user error.
Thanks a lot.
Is there a mailllist alert for new versions ?
For your info we had a similar problem 2 weeks back. I never thought to grab logs.
You can see the external URL ends then the 20:00 clock reverts to 19:59:59
We are on 206 2758 I see there has been an update, will install that now.
It looks like this may be related to the hard fixed time marker happening 1 second after the start of the last track of the hour. From the logs, it does appear to have started the podcast track, but then quickly advanced to the next track after about two seconds (which suspiciously is the same length as the fade time).
I will see if I can reproduce the issue in my controlled test environment. I assume you are running the latest version of PlayIt Live?
Attached wrong file, meant to add live assist and not user actions