Scalelite does not show screenshare, but all other formats are delivered

[opensourcecompany]

Deployment (required):

1. Deployment: docker-compose
2. Versions: latest (1.6.1)
3. Tools used for reproducing the issue: commandline

Describe the problem (required):
Scalelite gives back podcast and presentation, but not screenshare.

To Reproduce (optional):
fresh install.

Logs (may be required):
The query scalelite-api runs when requesting screenshare:

SELECT "playback_formats".* FROM "playback_formats" INNER JOIN "recordings" ON "recordings"."id" = "playback_formats"."recording_id" WHERE "playback_formats"."format" = 4c15ef688441abdab666da7f6da757164115d7b1-1723209552676 AND "recordings"."record_id" = screenshare ORDER BY "playback_formats"."format" ASC LIMIT 1

Result: empty. Even when directly accessing the webm-file, the frontend says failed unsupported request. Recordings are all not protected, forced them all to false in database.

When i do the lookup manually, i find the neccessary id = 2360:

scalelite=# select * from recordings where record_id = '4c15ef688441abdab666da7f6da757164115d7b1-1723209552676';
  id  |                       record_id                        |  meeting_id   |        name        | published | participants |   state   |        starttime        |         endtime         | deleted_at | protected | publish_updated
------+--------------------------------------------------------+---------------+--------------------+-----------+--------------+-----------+-------------------------+-------------------------+------------+-----------+-----------------
 2360 | 4c15ef688441abdab666da7f6da757164115d7b1-1723209552676 | 66a2642fb2331 | sample here abcxyz | f         |            1 | published | 2024-08-09 13:19:12.676 | 2024-08-09 13:19:47.916 |            | f         | f
(1 row)

So, to verify this, i run:

scalelite=# select * from playback_formats where recording_id = 2360;
  id  | recording_id |    format    |                                        url                                        | length | processing_time
------+--------------+--------------+-----------------------------------------------------------------------------------+--------+-----------------
 2714 |         2360 | notes        | /notes/4c15ef688441abdab666da7f6da757164115d7b1-1723209552676/notes.pdf           |      0 |
 2713 |         2360 | podcast      | /podcast/4c15ef688441abdab666da7f6da757164115d7b1-1723209552676/audio.ogg         |      0 |
 2712 |         2360 | presentation | /playback/presentation/2.3/4c15ef688441abdab666da7f6da757164115d7b1-1723209552676 |      0 |
 2716 |         2360 | screenshare  | /recording/screenshare/4c15ef688441abdab666da7f6da757164115d7b1-1723209552676/    |      0 |
 2715 |         2360 | video        | /playback/video/4c15ef688441abdab666da7f6da757164115d7b1-1723209552676/           |      0 |
(5 rows)

What might there be wrong?

[Ithanil]

The problem in the query is here:

"playback_formats"."format" = 4c15ef688441abdab666da7f6da757164115d7b1-1723209552676 AND "recordings"."record_id" = screenshare

format and record_id are swapped. It's an old bug, I stumbled across this more than a year ago. But when I fixed protected recordings in #1083 , I didn't notice it anymore for some reason. I have to take a look at it soon (although in our instance we don't serve screenshare format).