Author Topic: Undocumented (and some wrong) queue behaviours  (Read 1014 times)

quanta

  • Posts: 16
The XMPlay manual failed to specify the behaviours of queues in following manners:
- When a queued object is played, it is removed from the queue. Any remaining queued object has its queue value decreased by 1.
- If loop setting is set to Always Loop, XMPlay does not advance to the first object in the current queue after playback of current object reaches the end; otherwise XMPlay plays the first object in the current queue after playback of current object reaches the end.
- If there is no queued object, XMPlay plays remaining objects in general playlist in listed order, subjected to restrictions set by loop settings.
- When adding multiple objects into queue simultaneous, the orders they are added depend on the orders they are in the playlist, with top object appended to the queue first and the bottom object appended to the queue last. If some selected items are already in the queue, only the unqueued objects are appended, with the orders of existing queued objects unaffected.
- Pressing / (slash) button toggles queue status of a playlist object if 'Playlist->Toggle queueing' is enabled, otherwise it appends unqueue objects to queue and has no effect on already queued objects.
- Pressing Ctrl+/ button does not have effect to playlist object regardless of queue status or 'Playlist->Toggle queueing' setting. The current behaviour is a bug.
- When adding an object to a queue, XMPlay does not always assign the lowest unused queue value to the newly queued object, especially if an unload event took place before adding an object to a queue. The current behaviour is a bug.

Dotpitch

  • Posts: 2871
Re: Undocumented (and some wrong) queue behaviours
« Reply #1 on: 5 Feb '16 - 17:07 »
When adding an object to a queue, XMPlay does not always assign the lowest unused queue value to the newly queued object, especially if an unload event took place before adding an object to a queue. The current behaviour is a bug.
Could you describe the difference between what you expect to happen and what actually happens?

Zarggg

  • Posts: 1242
Re: Undocumented (and some wrong) queue behaviours
« Reply #2 on: 9 Feb '16 - 19:36 »
Many of your "undocumented behaviors" are expected behaviors based on the operation of the related functions (e.g., Always Loop). What is the source of your confusion?

quanta

  • Posts: 16
Re: Undocumented (and some wrong) queue behaviours
« Reply #3 on: 13 Feb '16 - 02:20 »
When adding an object to a queue, XMPlay does not always assign the lowest unused queue value to the newly queued object, especially if an unload event took place before adding an object to a queue. The current behaviour is a bug.
Could you describe the difference between what you expect to happen and what actually happens?

Let's say there are 10 files being put in the queue, then 5 of them are played, then the remaining ones will be numbered 1, 2, 3, 4, 5. However, if there is an unload event after 5 files are played, then 2 files are added to the queue, those 2 files don't always get numbered to 6 and 7.

quanta

  • Posts: 16
Re: Undocumented (and some wrong) queue behaviours
« Reply #4 on: 13 Feb '16 - 03:14 »
Many of your "undocumented behaviors" are expected behaviors based on the operation of the related functions (e.g., Always Loop). What is the source of your confusion?
Let's breakdown the original post point by point:
Quote
- When a queued object is played, it is removed from the queue. Any remaining queued object has its queue value decreased by 1.
The XMPlay manual fails to mention whether remaining queue objects are renumbered after an object is played or removed, which is an ambiguity. Queueing will work regardless, but users may not expect renumbering of queued items after a dequeueing event.
Quote
- If loop setting is set to Always Loop, XMPlay does not advance to the first object in the current queue after playback of current object reaches the end; otherwise XMPlay plays the first object in the current queue after playback of current object reaches the end.
The problem is, if the Auto loop is chosen, and the currently played object has built-in loopback, the should the queue be advanced after playback of current object reaches the end? The current queue advancement behaviour in XMPlay is different between Auto loop and Always loop.
Quote
- If there is no queued object, XMPlay plays remaining objects in general playlist in listed order, subjected to restrictions set by loop settings.
If 'Playlist->Show queue in playlist panel' is enabled, an user may incorrectly expect XMPlay will no longer play anything if no queued object remains, since the user can only see the entire playlist in the extended playlist from info window that may be obscured.
Quote
- When adding multiple objects into queue simultaneous, the orders they are added depend on the orders they are in the playlist, with top object appended to the queue first and the bottom object appended to the queue last. If some selected items are already in the queue, only the unqueued objects are appended, with the orders of existing queued objects unaffected.
Users may expect different behaviours for the above operations, which the current XMPlay manual do not explicitly contradict, as follows:
- For adding multiple objects into queue simultaneously, an user may expect queueing orders to depend on when the objects were selected instead of the order the objects in the general playlist. For example, selecting top 3 objects in the general playlist at the order of 3, 1, 2, then use enqueue command assigns objects 1, 2, 3 to queue numbers 2, 3, 1 respectively.
- For adding selected items that are already in the queue, an user may expect those already queued objects be put to the end of queue instead of maintaining their existing queue orders.
Those 2 possible interpretations of queue behaviours should be made into options, or be explicitly stated.
Quote
- Pressing / (slash) button toggles queue status of a playlist object if 'Playlist->Toggle queueing' is enabled, otherwise it appends unqueue objects to queue and has no effect on already queued objects.
An user may expect reordering of already queued objects when pressing / (slash) button with disabled 'Playlist->Toggle queueing' setting, as stated above.
Quote
- Pressing Ctrl+/ button does not have effect to playlist object regardless of queue status or 'Playlist->Toggle queueing' setting. The current behaviour is a bug.
- When adding an object to a queue, XMPlay does not always assign the lowest unused queue value to the newly queued object, especially if an unload event took place before adding an object to a queue. The current behaviour is a bug.
As originally posted, performing the actions do not deliver the expected results.

Dotpitch

  • Posts: 2871
Re: Undocumented (and some wrong) queue behaviours
« Reply #5 on: 13 Feb '16 - 09:09 »
Let's say there are 10 files being put in the queue, then 5 of them are played, then the remaining ones will be numbered 1, 2, 3, 4, 5. However, if there is an unload event after 5 files are played, then 2 files are added to the queue, those 2 files don't always get numbered to 6 and 7.
What is an 'unload event'? And what numbers do they get, 7 and 8?

Pressing Ctrl+/ button does not have effect to playlist object regardless of queue status or 'Playlist->Toggle queueing' setting. The current behaviour is a bug.
I assume you refer to the default shortcut for 'List track - Dequeue'? It properly dequeues the selected track over here, and leaves not-queued tracks untouched. Were you expecting something else?

Users may expect different behaviours for the above operations, which the current XMPlay manual do not explicitly contradict...
I agree that the queue behaviour you describe is not documented in the manual.