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/135API: Update API client, after Steering provides valid schema2023-07-24T16:05:49+02:00David TrattnigAPI: Update API client, after Steering provides valid schema## Parent: aura#192+
After [Steering provides a schema](https://gitlab.servus.at/aura/steering/-/issues/154 'Valid schema for "/steering/api/v1/playout" endpoint and add it to the OpenAPI Specification'):
* [ ] update the schema in `en...## Parent: aura#192+
After [Steering provides a schema](https://gitlab.servus.at/aura/steering/-/issues/154 'Valid schema for "/steering/api/v1/playout" endpoint and add it to the OpenAPI Specification'):
* [ ] update the schema in `engine/schemas`.
* [ ] re-generate the API client
* [ ] update any code working with the API client, if needed1.0-alpha5Chris 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/125[EPIC] Basic test suite for Engine2024-02-28T22:07:54+01:00David Trattnig[EPIC] Basic test suite for EngineParent: aura#175+
---
Test suite to cover the most important cases.
**Please note:** The `clock.py` test cases can be skipped for now, since we will [remove this code altogether](https://gitlab.servus.at/aura/aura/-/issues/312).
### S...Parent: aura#175+
---
Test suite to cover the most important cases.
**Please note:** The `clock.py` test cases can be skipped for now, since we will [remove this code altogether](https://gitlab.servus.at/aura/aura/-/issues/312).
### Sub Tasks
- https://gitlab.servus.at/aura/engine/-/issues/144+
- https://gitlab.servus.at/aura/engine/-/issues/143+
- https://gitlab.servus.at/aura/engine/-/issues/142+
- https://gitlab.servus.at/aura/engine/-/issues/137+
- Other test cases which look meaningful and improve the overall test coverage1.0-alpha5Chris PastlChris Pastlhttps://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/108Add active scheduling of "Station Fallback" in form of a default show2023-11-23T13:22:36+01:00David TrattnigAdd active scheduling of "Station Fallback" in form of a default show- Actively schedule Station Fallback when no planned timeslots are expected, to avoid wait time for silence detector
- Handle like a *Default Station Playlist*, similar to *Default Playlists* on schedule and show
### Dependencies
- htt...- Actively schedule Station Fallback when no planned timeslots are expected, to avoid wait time for silence detector
- Handle like a *Default Station Playlist*, similar to *Default Playlists* on schedule and show
### Dependencies
- https://gitlab.servus.at/aura/aura/-/issues/221+
- https://gitlab.servus.at/aura/aura/-/issues/176+1.0-alpha7https://gitlab.servus.at/aura/engine/-/issues/100[EPIC] Schedule programme data model without ORM/DB2024-03-26T14:44:33+01:00David Trattnig[EPIC] Schedule programme data model without ORM/DBThe recent programme data is continuously fetched from the Steering API. To avoid any disruption in play-out (e.g. in cases where the API is not available due to network outages) the programme is also cached locally.
Engine uses a SQLAl...The recent programme data is continuously fetched from the Steering API. To avoid any disruption in play-out (e.g. in cases where the API is not available due to network outages) the programme is also cached locally.
Engine uses a SQLAlchemy model rebuilding an internal representation of the programme and relevant schedules for play-out.
Having an ORM and relatively heavy PostgreSQL server just for this single purpose is some unnecessary overhead. Therefore lean ways of caching should be evaluated. This POC aims to:
1. Cache the raw JSON endpoint data
2. Rebuild the ORM using simple POPOs
3. Use hashing strategies to easily detect updates, where applicable
## Sub Tasks
- [x] #124+
- [x] #129+
- [x] https://gitlab.servus.at/aura/engine/-/issues/133+
- [x] Refactor API Fetcher
- [x] POC for `TimetableService` as a lightweight replacement for `ProgrammeService`
- [x] Diffing between current and planned schedule using JSON file cache
- [x] Refactor timetable renderer for work with new domain model
- [x] Test and integrate timetable and scheduler with new domain model
- [x] Refactor `scheduling` module to improve testability
- [x] Check if uses of `ProgrammeService.engine.engine_time()` can be relocated, to reduce dependencies
- [x] Remove all references of SQLAlchemy and PostgreSQL
- [x] Add some more test cases
- [x] Documentation: Update README.md
- [x] Update docs.aura.radio + Docker Compose settings
## Merge Requests
- https://gitlab.servus.at/aura/engine/-/merge_requests/35+
- https://gitlab.servus.at/aura/aura/-/merge_requests/40+1.0-alpha4 — Raving Raccoon 🤪🦝David TrattnigDavid Trattnighttps://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/77Graceful restart by keeping currently playing entry, in case it matches the o...2024-03-21T18:37:39+01:00David TrattnigGraceful restart by keeping currently playing entry, in case it matches the one to be scheduledWhen _Engine_ is crashing/restarting it normally (re-) schedules the entry which is planned per current timeslot. In case _Engine Core_ didn't crash though, it successfully kept playing the planned timeslot-entry. In such case no new sch...When _Engine_ is crashing/restarting it normally (re-) schedules the entry which is planned per current timeslot. In case _Engine Core_ didn't crash though, it successfully kept playing the planned timeslot-entry. In such case no new scheduling should happen i.e. when the playing entry is the one due to be scheduled.
Without the improvement, there is some Dead Air for some time, until the item is re-scheduled.1.0-alpha7Chris PastlChris Pastlhttps://gitlab.servus.at/aura/engine/-/issues/74Failure handling for invalid or broken Audio Streams2023-11-21T14:14:12+01:00David TrattnigFailure handling for invalid or broken Audio StreamsCurrent: Connecting to some invalid stream URL is continuously retried, which breaks other schedules.
Expected: Keep retrying, but only until the end of the playlist entry (expanded end-time, if no duration is provided via API)Current: Connecting to some invalid stream URL is continuously retried, which breaks other schedules.
Expected: Keep retrying, but only until the end of the playlist entry (expanded end-time, if no duration is provided via API)1.0-alpha5Chris PastlChris Pastlhttps://gitlab.servus.at/aura/engine/-/issues/56Set cue-points when queuing timeslots in progress2023-07-17T12:06:49+02:00David TrattnigSet cue-points when queuing timeslots in progressThe affects the boot phase of the engine, when it should be started playing in the middle of some timeslot.
Improve the existing, intermediate solution in a way, that
* The pre-rolling step should not be hearable (glitch sound)
* Use ...The affects the boot phase of the engine, when it should be started playing in the middle of some timeslot.
Improve the existing, intermediate solution in a way, that
* The pre-rolling step should not be hearable (glitch sound)
* Use an unified timer approach (`EngineExecutor`)
* Think about scenarios where such fast-forwarded of playlist entries is not wanted (Starting a timeslot late for some other reason than startup) or not possible (e.g. Stream, Live)
This feature might be of use, especially when some redundant infrastructure is used.1.1https://gitlab.servus.at/aura/engine/-/issues/49[STORY] As a host/programme coordinator, I want to assign a Playlist to a Tim...2023-07-17T12:01:57+02:00David Trattnig[STORY] As a host/programme coordinator, I want to assign a Playlist to a Timeslot after it has been started already, to override any undesired fallback scenarioTo allow intervention when no playlist has been assigned to an active timeslot, it should be possible to do so after the timeslot has started already. The assigned playlist starts from the beginning.
Related: #48To allow intervention when no playlist has been assigned to an active timeslot, it should be possible to do so after the timeslot has started already. The assigned playlist starts from the beginning.
Related: #481.1https://gitlab.servus.at/aura/engine/-/issues/48[STORY] As a host/programme coordinator, I want the ability to add entries to...2023-07-17T12:06:25+02:00David Trattnig[STORY] As a host/programme coordinator, I want the ability to add entries to a playlist which is currently playing / during play-out, when the playlist has not been populated properlyIt should be possible to add entries to a playlist which is currently in broadcast. Think about (expanded) live or stream entries in that context - here their length should be "re-expanded".
In case some removal or change of order of pl...It should be possible to add entries to a playlist which is currently in broadcast. Think about (expanded) live or stream entries in that context - here their length should be "re-expanded".
In case some removal or change of order of playlist entries has happened, no live update is performed.
Related: #491.1https://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.1