Lecton, Wędrowycz i kompresja audio

Jakiś czas temu[1], jeśli dobrze pamiętam w okolicach marca, InPost zrobił promocję dotyczącą paczkomatów. Wygrać można było nawet samochód, udział nie wiązał się z przekazaniem dodatkowych danych, więc wziąłem udział. Samochodu oczywiście nie wygrałem, za to wygrałem – jak wszyscy inni znani mi uczestnicy loterii – parę kodów dających dostęp do programu Lecton, czyli aplikacji Audioteka s.a pozwalającej na dostęp do audiobooków.

Lecton

Nieuchronnie będę porównywać z produktem Legimi, do którego dostęp uzyskałem wcześniej na podobnych zasadach. Są jednak różnice. Przede wszystkim Lecton rozlicza w postaci czasu dostępu do biblioteki, nie na sztuki. Także w promocji. Udało mi się w ten sposób poznać większą część cyklu o Jakubie Wędrowyczu.

Appka działała bez zarzutu. Być może kwestia niższych oczekiwań po kontakcie z Legimi, być może kwestia większej ilości miejsca na urządzeniu. W każdym razie słuchało się przyjemnie, intuicyjnie i bez walki z techologią. Oczywiście dostęp do książek jest tylko za pośrednictwem aplikacji, bez możliwości pobrania na urządzenia zewnętrzne, ale w modelu, gdzie płaci się za czas dostępu, nie za pozycje jest to zrozumiałe.

W ramach abonamentu korzystać można na jednym urządzeniu i jednym dodatkowym w trybie offline. Abonament to 20 zł/m-c (po prostu, bez promocji) Brak ebooków, tylko audiobooki, plus jakieś dodatki w stylu audycji cyklicznych itp. Mnie interesują tylko książki. Nadal – jest taniej, niż w przypadku Legimi, ale brak ebooków i mniejsza liczba urządzeń. Za Lecton ma prostsze warunki umowy – mniej wariantów i sumarycznie bardziej mi się podobał.

W Lecton drażni mnie tak naprawdę jedna rzecz – sposoby płatności. Nie ma klasycznego prepaid, trzeba podać albo kartę płatniczą, albo PayPala, żeby sobie pobierali opłatę abonament. Rozumiem, że subskrybcję można wyłączyć. Rozumiem, że tak jest prościej zaimplementować (i pewnie rozliczać), rozumiem, że tak jest korzystniej dla sklepu, bo klient nie może zapomnieć zapłacić, najwyżej zapomni wyłączyć subskrybcję. Wiem, że to coraz bardziej popularny model. Nadal drażni i finalnie doprowadziło do tego, że nie kupiłem abonamentu, wracając do książek tradycyjnych. Wiem, to nie jest dokładny odpowiednik, bo książki tradycyjnej nie posłucham w tramwaju.

Książki o Jakubie Wędrowyczu

Książki o Jakubie Wędrowyczu – wciągają. Znałem tylko pierwszy tom opowiadań, gdzie dominują krótkie utwory, w pozostałych tomach cyklu pojawiają się dłuższe. Jest niestety monotematycznie i z powtórzeniami, a żart opowiadany wielokrotnie przestaje bawić. Może kwestia dawki. Dodatkowo na przestrzeni cyklu pojawia się wiele niespójności, opowiadania są jakościowo różne. Niektóre naprawdę fajne koncepcyjnie, część to po prostu zgrabnie opowiedziane historyjki. IMO najsłabiej wypadają momenty, gdy zaczyna się politykowanie, często nachalne i znowu z powtórzeniami. Niemniej, warto. Całość jest ciekawa, zabawna, jako gawęda – zgrabna. Dodatkowo audiobooki są ładnie zaaranżowane i dobrze czytane. Chociaż tak w ogóle, po przeczytaniu opowiadań z 2586 kroków oraz Rzeźnika drzew mam wrażenie, że w utworach niewędrowyczowych Pilipiuk wypada lepiej.

Kompresja audio

Skoro przy audio jesteśmy – część techniczna, poniekąd będąca odpowiedzią na moje narzekania na zajmowane przez audiobooki miejsce. Audiobooki są duże, zapewne kompresowane do formatu MP3 lub zbliżonego. Tymczasem w przypadku mowy (audiobooki, podcasty itp.) nie potrzebujemy pełnego spektrum, więc można skorzystać z innych formatów, pozwalających na znacznie lepszą kompresję. Typowe MP3 to 128 kbps, tymczasem Speex pozwala na zejście do 4 kbps, lepiej wspierany na różnych playerach Opus na 7 kbps. Więcej opisane tutaj, a narzędzia są w repo. Prawdziwi hardcore’owcy mogą zejść nawet poniżej 1 kbps (dostępne sample).

[1] Kolejny wpis, który dość długo przeleżał w szkicach, a ostatecznie został opublikowany w niemal oryginalnej wersji.

Tąpnięcie

W pierwszej chwili myślałem, że posypały mi się statystyki. Nie zaglądam do nich często, ale strona ze statystykami jest otwarta w którejś tam zakładce w przeglądarce. Pewnego dnia ujrzałem ilość wejść na blog w okolicach zera. Była jedna czy dwie wizyty parę godzin wcześniej i… to wszystko. Odświeżenie strony nie pomogło. Korzystam z Matomo (dawniej Piwik) na własnym serwerze. Zatem jakaś awaria systemu, bazy czy koniec miejsca na dysku mogły mieć dokładnie taki efekt.

Posprawdzałem, nawet coś poprawiłem (drobny warning dotyczący bazy) i… Bez zmian, a spadek wizyt dotyczył tylko podstawowego bloga, nie wszystkich stron. Spojrzałem w Google Webmaster Tools, a w zasadzie w Search Console, bo teraz tak to się chyba nazywa i… Sprawa się wyjaśniła:

Blog w Google Search Console

Widać duży spadek przeciętnej pozycji w wyszukiwarce (z ~20 na ~60), idealnie skorelowany ze spadkiem wyświetleń (z ~800 na ~200). Który to spadek przekłada się na trochę większy niż czterokrotny spadek wizyt. Myślałem, że chwilowe przeindeksowanie. Zwłaszcza, że 04.08 w zasadzie wróciło do normy, wraz z wizytami na blogu, ale jak widać jest to raczej trwała zmiana.

Zapytałem wiedzących czy jest jakaś większa zmiana w Google. Ano jest, nazwa kodowa Maverick. Chociaż raczej chodzi o zmianę z pierwszego sierpnia. W każdym razie w Matriksie coś zmieniają.

Taka ciekawostka i ładny przykład, żeby się nie przywiązywać do strony, jej miejsca w wyszukiwarce i ilości wejść, skoro monopol na kształtowanie widoczności ma Google. W Search Console jest opóźnienie, więc jeszcze tego nie widać, ale patrząc na statystyki wizyt w ostatnich dniach wygląda, że sytuacja wraca do normy. I w sumie dobrze, bo nie mam weny na grzebanie w SEO.

PS Wpis pisany na raty, ostatecznie wygląda, że wizyty wracają do normy. Ziew.

Aktualizacja Debiana do Buster

Parę dni temu Debian ogłosił wydanie nowego stabilnego wydania o nazwie kodowej Buster. Skoro aktualizacja do Buster stała się możliwa, zacząłem ją natychmiast, ale dopiero teraz mogę nieco o niej napisać.

Przede wszystkim, pospieszyłem się. Szóstego lipca tylko zerknąłem na newsy i… pomyliłem poprzedniego newsa, dotyczącego wydania wersji 9.9 z wydaniem Bustera. Co prawda rzecz działa się już w trakcie wydawania (co widać było na Twitterze), ale zrobiłem lekki falstart.

Lekko zdziwił mnie brak release notes (zasługa falstartu). Ale większość rzeczy mam odseparowanych w kontenerach LXC, więc aktualizacje powinny proste, poza tym, który to już raz? Wziąłem na warsztat przy kawie jedną maszynkę fizyczną i kontenery LXC na niej. Kontenery poszły od kopa w stylu apt-get update && apt-get upgrade && apt-get update && apt-get dist-upgrade. Nie jest to zalecany sposób – w release notes jest napisane, by korzystać z apt. Nie wiedziałem o tym i… nie miało to znaczenia.

Aktualizacja hypervisora również gładka, kontrolny reboot i… kontenery się nie podnoszą. Co prawda apt-listchanges (polecam!) pisał, że LXC 3 got some significant changes from LXC 2, ale pozwoliłem zmienić konfigurację do nowej wersji, stosowane brakujące linie też były dodane. Wyszukiwarka nie pomagała, ludzie na kanale też nie. Z szybkiego upgrade od kawy zrobiła się godzinna walka z debugiem. Okazało się, że czyste, nowe kontenery z Busterem z minimalnym konfigiem także nie startują (error w loglevel INFO, hmm…):

# create
lxc-create -n test3 -t download -- -d debian -r buster -a amd64

# run
lxc-start -n test3 -l debug -o /tmp/debuuug.txt

# logs
tail -n 8 /tmp/debuuug.txt
lxc-start test3 20190706132233.984 NOTICE   start - start.c:start:2037 - Exec'ing "/sbin/init"
lxc-start test3 20190706132233.985 NOTICE   start - start.c:post_start:2048 - Started "/sbin/init" with pid "8584"
lxc-start test3 20190706132233.985 NOTICE   start - start.c:signal_handler:430 - Received 17 from pid 8582 instead of container init 8584
lxc-start test3 20190706132233.985 DEBUG    lxccontainer - lxccontainer.c:wait_on_daemonized_start:830 - First child 8580 exited
lxc-start test3 20190706132233.999 DEBUG    start - start.c:signal_handler:447 - Container init process 8584 exited
lxc-start test3 20190706132233.999 INFO     error - error.c:lxc_error_set_and_log:49 - Child <8584> ended on error (255)
lxc-start test3 20190706132233.999 DEBUG    network - network.c:lxc_delete_network:3180 - Deleted network devices
lxc-start test3 20190706132234.152 INFO     conf - conf.c:run_script_argv:356 - Executing script "/usr/share/lxcfs/lxc.reboot.hook" for container "test3", config section "lxc"

O dziwo kontenery w wersji ze Squeeze startowały. Doraźnie wróciłem w kontenerach do Squeeze (z backupu, nie downgrade) i na pewien czas zostawiłem sprawę. Mimo, że okazało się, że startują dość kulawo. Nie podnosiła się sieć ani nie uruchamiały usługi, trzeba to było robić ręcznie po każdym restarcie kontenera. Niefajne, ale do czasu znalezienia rozwiązania docelowego można wytrzymać, tym bardziej, że restarty są rzadkością.

Ostatecznie właśnie problemy ze startem i porównanie działania LXC na innym, świeżym hypervisorze z Buster, gdzie wszystko działało bez problemu naprowadziły mnie na rozwiązanie. Przy diagnostyce przy pomocy systemctl status otrzymywałem komunikat:

System has not been booted with systemd as init system (PID 1). Can't operate

Rozwiązaniem okazało się przejście na systemd i odinstalowanie pakietów związanych ze starym systemem init (niestety nie zapisałem nazw). IIRC na hypervisorze i w kontenerach. Po tym zabiegu wszystko działa poprawnie i startuje automatycznie, zarówno ze Squeeze w kontenerach, jak i po aktualizacji do Bustera.

Nie zaktualizowałem jeszcze wszystkich maszyn[1], ale z godnych odnotowania zmian – kontener generujący Planetę Joggera dostał aktualzację do Bustera bezpośrednio z Jessie zresztą[2]. Z działaniem na Squeeze był problem, na wersji testowej czy unstable także wtedy nie działało. Na szczęście jest już poprawione, co oznacza, że planeta ma szansę istnieć kolejne parę lat.

Ogólnie póki co aktualizacja całkiem przyjemna i prosta, o ile się ma systemd.

UPDATE: Na ostatnim serwerze napotkałem kolejny problem – skrypty w Pythonie korzystające z virtualenv przestały działać. Rozwiązanie łatwe do znalezienia po wpisaniu komunikatu – trzeba usunąć i utworzyć virtualenv na nowo. Dotyczyło zarówno Pythona 2 jak i Pythona 3.

[1] Został jeden serwer i jakieś desktopy na których akurat nie mam unstable i RPi robiące za router. Trochę boję się go zdalnie aktualizować, bo to zdalny system i nie mam żadnej alternatywnej łączności.

[2] Aktualizacja z przeskokiem wersji nie jest zalecanym sposobem. Jednak skoro to tylko okrojony kontener, który mogę w każdej chwili przywrócić z backupu, to czemu by nie spróbować?