Polskie radio w konsoli.

Dziś na kanale padło pytanie jak odtwarzać w konsoli radio z http://moje.polskieradio.pl? Na początku sądziłem, że chodzi o Trójkę itp., wtedy format URLa działający zarówno w mplayer jak i w MPD to wspominany we wpisie o MPD:

mms://stream.polskieradio.pl/program3

Okazało się jednak, że chodzi o pozostałe strumienie. I tu nie jest już tak różowo i prosto. Co prawda podczas poszukiwań (w sumie na koniec) ktoś natknął się na skrypt, który umożliwia odtwarzanie tych strumieni w konsoli, ale wędka lepsza od ryby więc:

  • Każda strona zawiera odtwarzacz w JS.
  • W kodzie odtwarzacza jest link do strumienia.
  • Link do odtwarzacza jest stały.
  • Link do strumienia również jest stały.
  • Strumień da się odtwarzać w mplayerze.

Przykładowo:

Minimax ma URL:

 http://moje.polskieradio.pl/station/33/Minimax

Player JS powstaje przez dodanie /_js/player.js, czyi ma URL:

 http://moje.polskieradio.pl/station/33/Minimax/_js/player.js

Strumienie są nazywane wg schematu k.stream, czyli szukamy:

wget -q -O - http://moje.polskieradio.pl/station/33/Minimax/_js/player.js| egrep "file.*k.*stream"

co daje nam wynik  _obj2.addVariable(’file’, 'k34.stream’);

Cały link do strumienia to:

rtmp://stream85.polskieradio.pl/live/k34.stream

Oczywiście nie dam głowy, że stream85 będzie stała i niezmienna, ale to również widać w źródle playera. Jedyną nieoczywistą częścią było dodanie live – wyłuskane z działających stacji (IIRC z Trójki).

Niestety, taką wersję obsłuży mplayer, ale już nie MPD. Jakby ktoś znalazł rozwiązanie jak tworzyć URL zdatny do MPD – proszę o info. Wersja ze skryptu odpada.

Wam życzę dobrego odbioru, a sobie, żeby stacje radiowe przestały utrudniać ludziom życie i dawały przyjazne konsolowym odtwarzaczom linki. Nie zawsze chce się/można włączyć ciężką przeglądarkę, by posłuchać radia. Niezrównanym ideałem jest tu dla mnie Radio Baobab, które nie tylko daje przyjazny konsoli format, ale również w wolnym formacie ogg (obok innych formatów) i w takiej formie, że się ładnie scrobble’uje.

UPDATE: Mpd w wersji 0.16.2 radzi sobie z URLami typu rtmp:// co oczywiście cieszy.

6 stycznia wolny – zysk czy strata dla pracowników?

Od pierwszego stycznia zmieniają się prawo pracy, a konkretnie zasady udzielania dni wolnych. Do tej pory, jeśli dzień wolny od pracy przypadał w sobotę, to pracownikowi przysługiwał w zamian za niego dzień wolny. Od 1 stycznia 2011 nie ma tego, za to do świąt dołącza 6 stycznia jako Objawienie Pańskie.
Zasadnicze pytanie: czy pracownicy na tym zyskują, czy tracą? Odpowiedź na to pytanie wbrew pozorom nie jest oczywista.
  • 1 stycznia
  • 1 maja
  • 3 maja
  • 15 sierpnia
  • 1 listopada
  • 11 listopada
  • 25 grudnia
  • 26 grudnia

(pomijam 4 święta ruchome, które w Polsce nigdy nie wypadają w sobotę), a do tego dochodzi od tego roku 6 stycznia.

Nie wdając się w matematykę (jakoś nie mam głowy do matematyki kalendarzowej, a nic sensownego mi nie wyszło przez chwilę namysłu), korzystam z metody najdoskonalszej, czyli pełnego przeglądu (AKA brute force) wg algorytmu: jeśli któreś z dotychczasowych świąt wypadnie w sobotę, to pracownicy tracą dzień, jeśli 6 stycznia nie wypadnie w sobotę ani w niedzielę, to pracownicy zyskują dzień.  I sumowanie strat i zysków…

Całość to nieładny bash (funkcja date) napędzana perlem, pisany na szybko.

Wynik? Miłe złego początki – przez najbliższe 10 lat stracimy, jako pracownicy, średnio rocznie 0,1 dnia wolnego, a w pierwszych 3 latach nawet będzie niewielki zysk, ale dla 25 lat – o ile przepisy się nie zmienią – stracimy łącznie 8 dni wolnych, czyli 0,32 dnia wolnego rocznie. Szczerze mówiąc, nie jest tak źle jak myślałem…

Ale zmiana jest ewidentnie niekorzystna dla pracowników. Gdyby miała miejsce w 1990 roku, to do tego roku tracilibyśmy średnio ponad pół dnia wolnego rocznie.

I skrypt do obliczeń:

Ile cyfr potrzeba, by numer konta był unikatowy?

Temat (nie)unikatowych numerów kont pojawił się w tej dyskusji nt. tokenów (dead link, domena przejęta), a szerzej opisany jest w tym wpisie, ile cyfr potrzeba, by numer rachunku bankowego był unikatowy. Przyznam, że nie miałem zielonego pojęcia nt. algorytmu weryfikacji numeru IBAN, ale na chłopski rozum kolizje zdarzą się wszędzie. Stwierdziłem, że najlepsza metoda nauki to napisać skrypt do sprawdzania. Oczywiście w Perlu. Przy okazji wyszło mi, że Perl średnio sobie radzi z dużymi liczbami, a Python dobrze, ale dzięki temu znalazłem pięknego gotowca w postaci modułu do sprawdzania poprawności numeru IBAN.

Pierwsze, co rzuca się w oczy, to fakt, że tak naprawdę numer IBAN jest zamieniany na liczbę, a czy jest poprawny określane jest tylko na podstawie jednego testu – jeśli reszta z dzielenia tej dużej cyfry przez 97 wynosi 1, to numer jest poprawny.

Chwila zabawy programem i okazuje się, że dla 3 brakujących cyfr w dowolnym miejscu rachunku można wygenerować ok. 10 kolizji. Pewnie ma to coś wspólnego z faktem, że 97 jest liczbą pierwszą, a samo 97 mieści się w każdym tysiącu właśnie 10-11 razy, ale tutaj już by się matematyk przydał i zasady podzielności przez 97 (hasło do Google cechy podzielności przez 97 nic sensownego nie znalazło niestety).

Inna szansa, że nasze PL na początku numeru (które wraz z następującymi po nim dwiema cyframi jest przesuwane na koniec i zamieniane na liczby patrz algorytm weryfikacji numeru IBAN) jest na tyle pechowe, że powoduje taką przykrą przypadłość. Ale to łatwo sprawdzić – dzięki użyciu ogólnej biblioteki skrypcik do bruteforce’owania numerów IBAN powinien działać dla wszystkich krajów.

Póki co konkluzja jest taka, że aby numer był unikatowy, to trzeba podać wszystkie cyfry. Przy dobrym wietrze może się zdarzyć, że 1 można opuścić.

PS. Nie cierpię słowa unikalny. Dla mnie oznacza ono możliwy do uniknięcia. Zamiast niego możnaby używać słowa unikatowy. Niestety SJP traktuje je jako synonimy.