Handle Queue Items After Livestream

rainbownapkin commented

2025-05-04 23:46:11 -04:00

(Migrated from gitlab.com)

Properly handle queue items after livestream has ended.

Give the user the option of either over-writing and skipping the items which where scheduled during the stream, or give them the option of pushing everything after the stream.

Properly handle queue items after livestream has ended. Give the user the option of either over-writing and skipping the items which where scheduled during the stream, or give them the option of pushing everything after the stream.

rainbownapkin commented

2025-05-04 23:46:11 -04:00

(Migrated from gitlab.com)

added #130 as parent issue

rainbownapkin commented

2025-05-04 23:47:38 -04:00

(Migrated from gitlab.com)

changed the description

rainbownapkin commented

2025-05-12 20:46:58 -04:00

(Migrated from gitlab.com)

Noticed a bug to keep an eye on:

When items are queued after stream begins, and the stream ends before said items, it plays those items as expected. However if the stream starts after an items starts, and ends before it ends, the item does not resume as expected.

This is because the refreshNextTimer checks for items in the queue, while items that have actually started playing are moved to nowPlaying.

goLive() manually sets the nowPlaying property of the queue class, and doesn't do anything with the current value, essentially tossing the only RAM copy of the media object.

While this isn't worth fixing before we start work on proper livestream/schedule handling, I should at least make a note to ensure that this is properly handled when this part of the codebase is worked.

Noticed a bug to keep an eye on: When items are queued after stream begins, and the stream ends before said items, it plays those items as expected. However if the stream starts after an items starts, and ends before it ends, the item does not resume as expected. This is because the refreshNextTimer checks for items in the queue, while items that have actually started playing are moved to nowPlaying. goLive() manually sets the nowPlaying property of the queue class, and doesn't do anything with the current value, essentially tossing the only RAM copy of the media object. While this isn't worth fixing before we start work on proper livestream/schedule handling, I should at least make a note to ensure that this is properly handled when this part of the codebase is worked.

rainbownapkin commented

2025-05-16 06:34:37 -04:00

(Migrated from gitlab.com)

mentioned in task #132

rainbownapkin commented

2025-05-16 06:37:05 -04:00

(Migrated from gitlab.com)

As mentioned in #132, we should create a collapsable queue prompt (a-la add media) which allows the user to name their Livestream and choose the scheduling mode (overwrite or pushback).

rainbownapkin commented

2025-05-18 18:06:00 -04:00

(Migrated from gitlab.com)

Livestreams now handle surrounding media properly. OverwriteSchedule DB mode has been completed. Livestreams will gracefully dissapear and fall back on to the standard schedule if the server stops or crashes during a livestream: 8c8b2a6f0b

Livestreams now handle surrounding media properly. OverwriteSchedule DB mode has been completed. Livestreams will gracefully dissapear and fall back on to the standard schedule if the server stops or crashes during a livestream: 8c8b2a6f0b942ae084c3819cdadde475a81597f0

rainbownapkin (Migrated from gitlab.com) closed this issue

2025-05-19 04:24:19 -04:00

rainbownapkin commented

2025-05-19 04:24:20 -04:00

(Migrated from gitlab.com)

Schedule Pushback mode fore Livestreams complete: b5e54afe99

Looks like there might be weirdness with this left but it's hard to tell. Might be worth keepin' an eye on. All the tests I run now seem good.

Schedule Pushback mode fore Livestreams complete: b5e54afe99156c3e448048b7272056680c876919 Looks like there *might* be weirdness with this left but it's hard to tell. Might be worth keepin' an eye on. All the tests I run now seem good.

Handle Queue Items After Livestream #136