Couple of edge cases

You found a bug or have any issues? Please post them here!
Post Reply
Bo98A
Posts: 86
Joined: 11 Apr 2016 21:29
Couple of edge cases

Post by Bo98A »

There's a couple of issues that I've noticed appear (rarely) over the past few months:
  1. Potential for tracks after a FTE to be played out of order. Say, for example, you have this scenario in a playlist:
    • Some track due to end a few seconds before HH:00:00
    • FTE at HH:00:00
    • Long track (large file size)
    • Short track (small file size)
    The FTE usually loads the subsequent tracks a few seconds before it is due to trigger, but it is possible that the 2nd track could load before the 1st track does, and if the track before the FTE ends within this time interval, then the tracks after the FTE will be played out of order. I've found it hard to reproduce this, but an embedded container with multiple tracks might make it easier than just a single long track. Embedded containers is what I typically have for the first two items after the FTE.
  2. A program calendar lock prevents scheduled playlist template programs from playing properly. There has been a couple of unfortunate moments where a program calendar was opened by another PC which happened to be when ProppFrexx is loading the next program. If this next program is a playlist template program, then the playlist will not be loaded but rather the script that created the playlist will run. This doesn't seem to happen with programs that are not from a pre-generated playlist. Since ProppFrexx handles this fine with simple scripted programs, should it not also work with playlist template programs?
Bo98A
Posts: 86
Joined: 11 Apr 2016 21:29
Re: Couple of edge cases

Post by Bo98A »

radio42 wrote: 18 Apr 2018 14:43 So maybe you are more taking about a TUS (i.e. you have defined your FTE also as a TimeUpdateSync)?
Yes, I'm talking about TUS. Apologies for the confusion.
radio42 wrote: 18 Apr 2018 14:43 6 seconds is actually a pretty long time. I might give an option to configure that time (e.g. to increase it), but you indeed should check, why loading those tracks/containers take that long?!
Are you maybe using a slow device where your tracks are located on or are you using a network connected device and your network connection times out at that moment?
The 6 second window isn't the issue here. Let's say the TUS was at HH:00:00, and the "long track" took 0.25 seconds to load, while the "short track" took 0.1 seconds (completely arbitrary numbers here). If the tracks start loading 6 seconds before (HH:59:54), and the track before the TUS ended between HH:59:54.10 and HH:59:54.25 then the second track will play first. I know this is a very small window and extremely unlikely to happen, but it has happened twice I've been told. An embedded container will probably widen this window a little bit.

I will see if I can reproduce it as admittedly I've not been around whenever the issue surfaced.
radio42 wrote: 18 Apr 2018 14:43 So there are some possibilities:
- the playlist file is indeed not present
- the playlist file is available, but all the files contained in the playlist are not accessible (e.g. due to a path error)
- the start date and time of the program entry was changed after the playlist was pre-generated (so that the macros are resolved differently)
The issue has surfaced on several occasions and only ever when Program.calendar.~lock is present. Attempting to load the program after it is cleared works perfectly so the setup of the program must be ok. I will however investigate this further to see if I can get more information on this.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: Couple of edge cases

Post by radio42 »

to 1: yes, this scenario is exactly, what I tried to describe. While the 'long track' is still loading, but the 'short track' has been loaded already and now the current track ends: only the 'short track' is available for playout - thus it is played.

I guess the main issue here is, that a TUS is designed to kick in late; i.e. why would your previous track end early and no other track is available at that time? In your case the TUS comes in early.
So maybe you are indeed using a FTE, but you wouldn't/shouldn't use the 'As TimeUpdatSync' option?! Have you tried that?


to 2: yes, I assume, we would need more info here.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: Couple of edge cases

Post by radio42 »

to 1:
If I understand you correctly, I guess this is by design. I.e. when the FTE is due to start, but the 'large track' hasn't been loaded, but the 'small track' already did and you are using 3 DJ Players, there is other track ready to be played. So the system decides to play the track being ready instead of leaving the system with dead air.
A FTE however (unless you are talking also about a TimeUpdateSync) does NOT load subsequent tracks ahead of time (it actually cannot do this, as the other players might still be in use!). A subsequent track however is only loaded, when a player becomes empty.
So maybe you are more taking about a TUS (i.e. you have defined your FTE also as a TimeUpdateSync)?
As yes, a TUS is executed 6 seconds ahead of its time.
A TUS might than eject any previous (unplayed) tracks and then load the subsequent tracks.

Assume you previous track (the one before the FTE or TUS) is just about to end, but is still playing in player A.
Now the subsequent tracks will tried to be loaded into player B and C.
If the loading is not completed for player B (and this is the pure loading time, meaning initializing the audio file from your hard disk, this does NOT include any WaveForm rendering!), but now player A did end. At that moment the system will try to start playing player B.
But if player B isn't ready yet, but player C is, than the system will instead play player C!
As said, this is by design.
In case this is happening, you should check you IO-sub-system, why it takes more than 6 seconds to initialize a track (reading/accessing it). Initializing a track means simply reading it in, i.e. scanning all frames and reading its TAG data. If that takes more than 6 seconds.
For embedded containers, all contained tracks might be evaluated/read.

6 seconds is actually a pretty long time. I might give an option to configure that time (e.g. to increase it), but you indeed should check, why loading those tracks/containers take that long?!
Are you maybe using a slow device where your tracks are located on or are you using a network connected device and your network connection times out at that moment?

Nevertheless, there might be even other scenarios, where a playlist order might be shifted (in order to prevent dead air/silence).
E.g. think of the following sequence:
Player A: currently playing a track with a 10 second fade-out after the Next cue-point
Player B: about to play a 5 second jingle, but having a NEXT cue-point set at the very beginning of the track!
Player C: about to play 1 second station id
When now Player A reaches its Next cue-point, it starts player B, which again triggers playing player C at almost the same time.
Now Player C will finish before A and B...and load the next track, which might by itself start right away... etc.
This will also shift the sequence because of the long fades of A...


to 2:
I guess your assumption is (unfortunately) wrong. The program calendar lock cannot prevent a next program to start properly, because the lock is only evaluated when you start/open the program scheduler dialog - but nowhere else!
As such, a lock on the program calendar file cannot prevent the playback of a pre-defined playlist file.
The only reason, why a pre-generated template playlist file could not be played is, because it could not be found on your system.
Note, that once you create a template playlist file, a new script will automatically be created in the background.
That script consists of exactly 2 script-lines: the 1st one loads the playlist file, and it uses macros to resolve the dynamically generated folder and filename; the 2nd executes the original template script in a loop.
As such, when this pre-generated program/playlist is about to be started by the scheduler, that script is executed.
If it cannot find the physical playlist file accordingly after resolving the used macros (which denote the effective start date and time), that 1st script-line is skipped and simply the original script is executed - just like you described it.
So there are some possibilities:
- the playlist file is indeed not present
- the playlist file is available, but all the files contained in the playlist are not accessible (e.g. due to a path error)
- the start date and time of the program entry was changed after the playlist was pre-generated (so that the macros are resolved differently)
You need to check these possibilities.


All in all, I am afraid, that both issues not really bugs.

Post Reply