Informace v RDS službách, které poskytují dříve uvedné služby jsou občas skutečně netypické. Tedy ve smyslu jejich strategie zpracování. Například některé stanice ČRo (zdroj dat radia.cz ) používají RDS následovně:
Tohle například u takové Evropy 2 ze zdroje rds.actve.net funguje vcelku bez problémů a očekávaně. Tedy pokud pomineme to, že občas se data na novou skladbu nepřepnou. To ale nemá vliv na způsob zpracování, resp. strategii řízení přístupů k serveru služby. I tady to samozeřejmě vede v tomu, že se přejde na cyklické dotazy. Například v případě, kdy nedojde k přepnutí dat na přehrávanou skladbu v uvedený čas nebo dokonce vůbec (i to se stává) nebo při vstupu moderátora, reklamních přestávkách nebo zprávách, kdy v RDS zůstávají data naposledy hrané skladby, často po poměrně dlouhou dobu. Ale takhle RDS prostě funguje.
Jak to funguje je vidět v logu Kodi. Nejdříve se přehrává stanice Frekvence 1 (je v datové struktuře addon-u, která popisuje zdroje RDS zadaná pod alias F 1), pak jsem přepnul na Evropu 2. Jsou tam vidět chvíle, kdy se data začnou načítat periodicky (s periodou 5 s) po proběhnutí doby anoncovaného konce skladby.
No a když jsme se už zmínil o těch datech, tak ještě krátce k datové struktuře, která by měla pomoci řídit načítání dat z akceptovaných zdrojů. Akceptace znamená, že pro každý takový zdroj bude existovat modul, ve kterém bude probíhat jeho dekódování. Zatím mám tu datovou strukturu definovanou a naplněnou přímo v datech kódu addon, je ale jasné, že ve finále tohle bude mimo, v json souboru. Předpokládám default data uložená v adresáři addon a uživatelsky definovatelná, uložená v uživatelsky dostupném (zadaném) adresáři, kterou se ta default doplní/přepíše.
Tak už se blíží zveřejnění části service, které plánuji to v novém roce. Vizualizace bude zatím možná jen na upraveném skinu Estuary-Easy. Tu úpravu samozřejmě popíšu pro ty, kteří jsou schopni si skin Estuary upravit sami.
Pokusím se co k tomu udělat i "univerzální" vizualizaci ve formě script části s default definicí souboru skinu, která by byla použitelná na jakémkoliv skinu, případně by se pro tam další vybrané skiny doplnila vizualizace ve shodném tvaru, ale to si ještě nějaký další čas vezme. Pak je ještě varianta zápisu RDS dat do datových struktur PVR, ale to je tak trochu alchymie a je otázka, zda tohle vůbec půjde nějak snadno udělat.
- běží nějaký pořad, v RDS je název pořadu, čas začátku a konce jsou časy začátku a konce pořadu,
- v rámci daného pořadu hraje skladba, v RDS je název skladby, čas začátku a konce jsou časy začátku a konce této skladby a dokonce občas čas konce skladby chybí,
- po skončení skladby se informace v RDS vrátí na ty původní, vztažené k pořadu.
Tohle například u takové Evropy 2 ze zdroje rds.actve.net funguje vcelku bez problémů a očekávaně. Tedy pokud pomineme to, že občas se data na novou skladbu nepřepnou. To ale nemá vliv na způsob zpracování, resp. strategii řízení přístupů k serveru služby. I tady to samozeřejmě vede v tomu, že se přejde na cyklické dotazy. Například v případě, kdy nedojde k přepnutí dat na přehrávanou skladbu v uvedený čas nebo dokonce vůbec (i to se stává) nebo při vstupu moderátora, reklamních přestávkách nebo zprávách, kdy v RDS zůstávají data naposledy hrané skladby, často po poměrně dlouhou dobu. Ale takhle RDS prostě funguje.
Jak to funguje je vidět v logu Kodi. Nejdříve se přehrává stanice Frekvence 1 (je v datové struktuře addon-u, která popisuje zdroje RDS zadaná pod alias F 1), pak jsem přepnul na Evropu 2. Jsou tam vidět chvíle, kdy se data začnou načítat periodicky (s periodou 5 s) po proběhnutí doby anoncovaného konce skladby.
No a když jsme se už zmínil o těch datech, tak ještě krátce k datové struktuře, která by měla pomoci řídit načítání dat z akceptovaných zdrojů. Akceptace znamená, že pro každý takový zdroj bude existovat modul, ve kterém bude probíhat jeho dekódování. Zatím mám tu datovou strukturu definovanou a naplněnou přímo v datech kódu addon, je ale jasné, že ve finále tohle bude mimo, v json souboru. Předpokládám default data uložená v adresáři addon a uživatelsky definovatelná, uložená v uživatelsky dostupném (zadaném) adresáři, kterou se ta default doplní/přepíše.
Kód:
channels = {'Evropa 2': ('actve', 'evropa2'),
'F 1': ('actve', 'frekvence1'),
'Frekvence 1': ('@', 'F 1'),
'Radio DANCE radio': ('actve', 'danceradio'),
'Radio Bonton': ('actve', 'bonton'),
'CRo RADIOZURNAL': ('radio', '273'),
'CRo RADIO WAVE': ('radio', '274'),
'CRo VLTAVA': ('radio', '275'),
'CRo JAZZ': ('radio', '276'),
'CRo RADIO JUNIOR': ('radio', '277'),
'CRo PLUS': ('radio', '278'),
'CRo DVOJKA': ('radio', '279'),
'CRo D-DUR': ('radio', '280')}
services = {'actve': 'https://rds.actve.net/v1/metadata/channel/%s?coverSize=600',
'radio': 'https://data.radia.cz/data/pravehraje/new-%s-currentnext.json'}Tak už se blíží zveřejnění části service, které plánuji to v novém roce. Vizualizace bude zatím možná jen na upraveném skinu Estuary-Easy. Tu úpravu samozřejmě popíšu pro ty, kteří jsou schopni si skin Estuary upravit sami.
Pokusím se co k tomu udělat i "univerzální" vizualizaci ve formě script části s default definicí souboru skinu, která by byla použitelná na jakémkoliv skinu, případně by se pro tam další vybrané skiny doplnila vizualizace ve shodném tvaru, ale to si ještě nějaký další čas vezme. Pak je ještě varianta zápisu RDS dat do datových struktur PVR, ale to je tak trochu alchymie a je otázka, zda tohle vůbec půjde nějak snadno udělat.