Rename fallback_id to default_id

Output of the meeting on 2020-11-10: the term fallback_id is mostly irritating, as it was initially thought to handle default playlists, if no other playlist is set (as a standard mode of operation). Only when a station fallback is active we want to treat it actually as an error.

Therefore we should rename the fallback_id fields in steering to default_id for each "show" and "timeslot".

Would be good to already change in Aura 1.0, but can also be moved to 1.1 in case of doubt. Whenever this is closed a dashboard and engine ticket (with the same milestone) should be opened to adapt to the new change. Any other thoughts on that @david @pretzelhands ?

changed milestone to %1.0-alpha2 — Precise Pheasant

added P3 label

changed the description

added To Do label

marked this issue as related to engine#52 (closed)

marked this issue as related to dashboard#65 (closed)

Required to finalize engine#52 (closed)

Some notes @jackie:

1. What is the naming scheming for this field to be used? "default_id" is ambiguous, bcuz it's not clear what it is referencing. "default_playlist_id" might be okay but somewhat lengthy when used in the playout API endpoint like "default_schedule_playlist-id". What do you think?

2. Please also note the API Spec at https://gitlab.servus.at/aura/meta/-/blob/master/docs/api-definition.md has to be updated.

3. Please note that a major other difference between "fallback" and "default" playlists is, that the latter don't work using a silence detector concept. In other words they don't jump back and forth when e.g. silence is detected during a live show or if some web stream has connection problems. In such scenario only the station fallback will kick in. Default playlists have a full "replacing nature" meaning when there is no specific playlist at playout, then the default one is used. When there is a specific one, that this one is used. Simple as that. This was discussed and agreed in the meeting with @pretzelhands and @sarah.kanawin on 2020-11-16. Does that sound okay for you?

4. Also, because it's somewhat related, the API Spec holds a field "station_fallback_id". In some meeting in spring we decided that it's okay to configure the station fallback handling locally at the engine (as it is now). Should we keep that property in the API for future implementation or ditch it?

mentioned in issue dashboard#77 (closed)

marked this issue as related to dashboard#77 (closed)

Also worth noting, I keep the existing "schedule and show fallback logic" in engine, as it is working. Engine will also keep querying the fields "schedule_fallback_id" and "show_fallback_id" from any Steering API records, as fallback vs. default are basically distinct features. It will be simply not documented for now that this fallback feature exists (other than the station fallback).

mentioned in issue engine#52 (closed)

Sorry if I only addressed @jackie, these notes are also relevant for @nnrcschmdt. Please decide for yourself who will implement this. My part of this is already finished using this workaround: https://gitlab.servus.at/aura/engine/-/blob/master/src/scheduling/api.py#L124-130.

As soon you have committed your code, please let me know and I will remove the workaround from the codebase.

assigned to @nnrcschmdt

added Doing label and removed To Do label

changed milestone to %Aura 0.9

added P1 label

removed P3 label

changed the description

@nnrcschmdt changed priority on this to #P1 since Dashboard and Engine changes depend on this. I think it also involves a DB change on your side? So it might be better to avoid future migrations here to.

Sorry for taking so long @david & @pretzelhands

closed

Thanks @nnrcschmdt, I'm reopening the ticket though, because of:

• "station_fallback_id" should not be renamed, because it actually acts as a "Fallback" using the Silence Detector (see above). Currently the station fallback ID is set locally in the Engine Config. So we might not need it at all. Let's discuss in the meeting today.
• Please also update the API Spec according to the final changes.

reopened

I removed the STATION_DEFAULT_ID/STATION_FALLBACK_ID from the settings and the use in the views.

I also have a merge request on meta for the changes in the documentation.

closed

reopened

@nnrcschmdt As I wrote in via PM the note 1.) here #54 (comment 1876) got somehow lost. Would be great if you could change this small but quite expressive difference ;-)

Renamed all instances of default_id to default_playlist_id and added a migration to renamed the fields in the database.

cc: @david , @pretzelhands

closed

removed Doing label

marked this issue as related to #64 (closed)

removed the relation with #64 (closed)

marked this issue as related to #65 (closed)

removed the relation with #65 (closed)