engine issueshttps://gitlab.servus.at/aura/engine/-/issues2024-02-28T16:56:33+01:00https://gitlab.servus.at/aura/engine/-/issues/144Improve test coverage of `aura_engine/base/lang.py`2024-02-28T16:56:33+01:00David TrattnigImprove test coverage of `aura_engine/base/lang.py`Parent: https://gitlab.servus.at/aura/engine/-/issues/125+
---
Based on the [orm-less-scheduling](https://gitlab.servus.at/aura/engine/-/tree/orm-less-scheduling?ref_type=heads) branch or after engine#100 is merged to `main`.Parent: https://gitlab.servus.at/aura/engine/-/issues/125+
---
Based on the [orm-less-scheduling](https://gitlab.servus.at/aura/engine/-/tree/orm-less-scheduling?ref_type=heads) branch or after engine#100 is merged to `main`.1.0-alpha5Chris PastlChris Pastlhttps://gitlab.servus.at/aura/engine/-/issues/142Improve test coverage of `aura_engine/plugins/monitor.py`2024-03-18T20:47:26+01:00David TrattnigImprove test coverage of `aura_engine/plugins/monitor.py`Parent: https://gitlab.servus.at/aura/engine/-/issues/125+
---
Based on the [orm-less-scheduling](https://gitlab.servus.at/aura/engine/-/tree/orm-less-scheduling?ref_type=heads) branch or after engine#100 is merged to `main`.Parent: https://gitlab.servus.at/aura/engine/-/issues/125+
---
Based on the [orm-less-scheduling](https://gitlab.servus.at/aura/engine/-/tree/orm-less-scheduling?ref_type=heads) branch or after engine#100 is merged to `main`.1.0-alpha5Chris PastlChris Pastlhttps://gitlab.servus.at/aura/engine/-/issues/138No playout after engine reboot if timeslot has already started2024-03-26T16:18:46+01:00Chris PastlNo playout after engine reboot if timeslot has already startedTried to start the playout by manually creating a timeslot in the DB and adjusting its start/stop time.
**Works as expected if timslot_start is in the future.**
If current time is between `timeslot_start` and `timeslot_end` - which wil...Tried to start the playout by manually creating a timeslot in the DB and adjusting its start/stop time.
**Works as expected if timslot_start is in the future.**
If current time is between `timeslot_start` and `timeslot_end` - which will be probably true after (re)starting the engine - no scheduled playout will start until the next timeslot.
![Bildschirmfoto_2023-09-19_um_17.53.41](/uploads/f43b590bf409c14821dbf0f567c99972/Bildschirmfoto_2023-09-19_um_17.53.41.png)
```bash
2023-09-19 17:53:50,270:engine:INFO - Finished loading local programme (0 timeslots) - [programme.py:94-refresh()]
2023-09-19 17:53:50,271:engine:INFO - Finished queuing programme. - [scheduler.py:285-queue_programme()]
```1.0-alpha4 — Raving Raccoon 🤪🦝David TrattnigDavid Trattnighttps://gitlab.servus.at/aura/engine/-/issues/137Test cases for "src/aura_engine/core"2024-03-14T22:37:17+01:00David TrattnigTest cases for "src/aura_engine/core"Parent: #125+
---
Implement test cases with good code coverage.Parent: #125+
---
Implement test cases with good code coverage.1.0-alpha4 — Raving Raccoon 🤪🦝Chris PastlChris Pastlhttps://gitlab.servus.at/aura/engine/-/issues/131Virtual Timeslots: Remove workarounds and replace with Steering's native appr...2023-11-02T12:46:11+01:00David TrattnigVirtual Timeslots: Remove workarounds and replace with Steering's native approachParent: aura#176+
---
- Remove the config for station fallback show and current workaround to create virtual timeslots
- Compare the final implementation in Steering: steering#154
- After Steering `/playout` endpoint has a [valid schema...Parent: aura#176+
---
- Remove the config for station fallback show and current workaround to create virtual timeslots
- Compare the final implementation in Steering: steering#154
- After Steering `/playout` endpoint has a [valid schema](steering#154), also update the schema in `engine/schemas/openapi-steering.json`1.0-alpha5https://gitlab.servus.at/aura/engine/-/issues/118Read playlist information from Steering API, instead of Tank API2023-07-17T12:09:02+02:00David TrattnigRead playlist information from Steering API, instead of Tank APIAs part of [AEP05](https://gitlab.servus.at/aura/aura/-/wikis/AEP05-Erweiterung-Datenmodell) Tank Playlist information is pushed to Steering upon assignment to a Timeslot. Additional Playlist Metainformation might be added to Steering ti...As part of [AEP05](https://gitlab.servus.at/aura/aura/-/wikis/AEP05-Erweiterung-Datenmodell) Tank Playlist information is pushed to Steering upon assignment to a Timeslot. Additional Playlist Metainformation might be added to Steering timeslots also.
This means all playlist data can be read together with other calendar information using a single `GET` request to `/steering/api/v1/playout`.
As a consequence this also has some positive non-functional effects:
- Reduced API requests per scheduling cycle (currently 1 to Steering and (n) to Tank for every single playlist, every 30 seconds)
- De-coupling of Engine and Tank. The only API interaction left between these two, is on a file-system basis when accessing audio files.1.1https://gitlab.servus.at/aura/engine/-/issues/97POC: Use Asyncio instead of Threads2022-01-25T19:13:57+01:00David TrattnigPOC: Use Asyncio instead of ThreadsRefactor Engine to use [asyncio](https://docs.python.org/3/library/asyncio.html) instead of Threads. This is considered primarily an *nice to have* enhancement. The aim is to provide a more elegant, robust and readable implementation. Ex...Refactor Engine to use [asyncio](https://docs.python.org/3/library/asyncio.html) instead of Threads. This is considered primarily an *nice to have* enhancement. The aim is to provide a more elegant, robust and readable implementation. Existing functionality should not change.
Ensure all of these do work the same way as currently with using Threads:
- Timed execution of engine control threads
- API fetch threads and programm update cycles
- Liquidsoap client threads1.1https://gitlab.servus.at/aura/engine/-/issues/92Refactor playlists not allowing combinations of different entry types2023-07-17T12:01:31+02:00David TrattnigRefactor playlists not allowing combinations of different entry typesThe original Tank Playlist API and Dashboard UI was designed with a generic approach in mind. This allows mixing of all entry types in a single playlist. That means a playlist can consist of:
- Files entries
- Analog Source entries
- St...The original Tank Playlist API and Dashboard UI was designed with a generic approach in mind. This allows mixing of all entry types in a single playlist. That means a playlist can consist of:
- Files entries
- Analog Source entries
- Stream entries
**This results in two types of challenges:**
**1. User Experience challenges:** The user cannot expect what happens when some source fails. For example live sources are typically meant to be played at a fixed broadcast window. Files sources on the other hand are typically a queue, which should allow adding new entries on the fly. Given following example of a playlist:
```
00:00 - file#1
00:05 - file#2
00:10 - file#3
00:15 - live broadcast
00:30 - file#5
00:45 - file#6
```
As a consequence playlists consist of two different types of artifact: a.) queueable and b.) fixed frame audio sources which naturally don't belong together in the same playlist.
When some of the first files fail to be played for any reason, there is a gap between files and live source. This is automatically filled with audio from the silence detector. So far so good. But the user might not be aware when the live broadcast starts playing, as in its perception it should be after file#3. Likely, the host misses to broadcast the live segment in time. It think it's imaginable, that this can cause multiple reasons for frustration.
YAGNI: After gathering feedback from people from different radios, the uses case of mixing playlist entry types seems not to be required.
When there are situations to mix pre-produced content with live content, this always can be done using a media player in the live studio.
**2. Technical challenges:** While the current implementation of Engine actually manages to provide this feature based on the given API, the resulting code is relatively complex in contrast to the benefits of this functionality. Also, building means of intervention (during a show) on top of that raises the bar for complexity further. Therefore it breaks the KISS principle.
**Solution:** This ticket aims to remove such feature altogether, allowing a much lighter implementation. Also, it serves for better understanding the underlying mechanics for end-users. I am suggesting to only allow a playlist consisting with one of these:
- Multiple file entries.
- A single live source entry
- A single stream source entry
(Required UI restrictions will be provided at a later stage)1.1https://gitlab.servus.at/aura/engine/-/issues/89Support for SQLite2024-03-06T18:46:45+01:00David TrattnigSupport for SQLiteBlockers:
- ~~#93+~~
- #98+Blockers:
- ~~#93+~~
- #98+1.0-alpha4 — Raving Raccoon 🤪🦝David TrattnigDavid Trattnighttps://gitlab.servus.at/aura/engine/-/issues/82Test and fine-tune playout timings2024-03-21T18:37:15+01:00David TrattnigTest and fine-tune playout timings1.0-alpha6Chris PastlChris Pastlhttps://gitlab.servus.at/aura/engine/-/issues/47[EPIC] Playout: Possiblities of Intervention2023-07-17T12:06:44+02:00David Trattnig[EPIC] Playout: Possiblities of Intervention
## User Stories
- engine#46+
- engine#48+
- engine#49+
- dashboard#90+
- ...
## User Stories
- engine#46+
- engine#48+
- engine#49+
- dashboard#90+
- ...1.1https://gitlab.servus.at/aura/engine/-/issues/25[STORY] As a programme coordinator, I want a jingle being played after every ...2023-10-18T17:15:31+02:00David Trattnig[STORY] As a programme coordinator, I want a jingle being played after every 3 random music pool tracks, in order to keep the programme more dynamic and livelyFor random music, there should be the option to include a Jingle every (n) tracks (FRF 3x audio, 1x jingle)
Relates to Fallback Scenario: Play Random Music #43, #13 and involves work on `engine-core`For random music, there should be the option to include a Jingle every (n) tracks (FRF 3x audio, 1x jingle)
Relates to Fallback Scenario: Play Random Music #43, #13 and involves work on `engine-core`1.1