Youtube Frontend 1.5.0

Megint itt egy új eresztés, most kimondottan sok újítással.

Újdonságok:

- Lett "Summary window", ami első induláskor feljön és tájékoztat, hogy mit talált, de később is elő lehet csalni Ctrl + S kombóval.

- A kiválasztható formátumok innentől kombinálhatóak, azaz ami csak audio, meg csak video azokat a program összepárosítja és lehet őket együtt lejátszani. (A kép klikkre megnő.)

- Ezzel kapcsolatban a playerek beállítása is megújult:

  • Egyrészt a format flag-et külön kell innentől megadni és a {FORMAT} template-et többé nem kell (nem szabad) enkapszulálni.
  • Másrészt, ha egy ilyen párosított stream-et választunk és direkt URL átadást állítottunk be (ld. később), akkor egyrészt itt be kell állítani, hogy a lejátszó milyen flag-gel tud külső audiofájlt behúzni a kép mellé, másrészt pedig a parancssorba be kell illeszteni az {AURL} template-et, hogy használni is tudja.

- A Prefs panelen átrendeztem az elemeket, mert már nagy volt a katyvasz, így most funkció szerint vannak csoportosítva.

Ebből a képből már az is látszik, hogy vannak újdonságok is rajta. Pl.:

- Mint a playereknél is, a letöltőparancsnál is innentől külön mezővel kell specifikálni a format flag-et. Így többé nincs az a probléma, hogy vagy nem lehet formátumot választani (mert nincs is {FORMAT} template a parancssorban), vagy kötelezően kell (különben pl. youtube-dl esetén a -f "{FORMAT}"-ból -f "" lesz és nem fog működni...)

- Mint a múltkor megénekeltem, a program most már maga is képes kiberhelni a tecső örvénylő fostengerének mélyéről a közvetlen URL-eket a stream-ekhez és ezeket át is tudja adni a playernek és a letöltőnek. A playernél már leírtam fentebb, hogy mik kapcsolódnak ide; na ez az a bizonyos URL átadás. Értelemszerűen, ha az URL átadás közvetlen linkkel történik, akkor fogja használni a program az {AURL} template-et, ha az eredeti tecső linkkel, akkor pedig a {FORMAT} template-et.

- Majdnem ugyanígy van a letöltőnél is, csak itt nincs értelme az {AURL}-nek, ha direkt linket használ az ember, hanem helyette két letöltőparancsot fog a vágólapra másolni, ha másolod a letöltőparancsot, ill. maga a program direktben fogja letölteni, ha le akarod tölteni. Egyébiránt ez az opció - már, hogy a letöltés direkt linkekkel menjen - nem kimondottan javasolt, legalábbis a szeparált streamek esetén - a következők miatt:

  • A tecső valamiért az összes szeparált stream-et (azaz audio-only, vagy video-only stream-ek) 0.000001 yoctobit per millenniummal streameli le a programnak, legalábbis nálam ezt csinálta. Érdekes, hogy ez sem a youtube-dl-nél, sem a külsős letöltőknél (curl és tsai.), sem a playereknél (mpv, vlc, stb.) nem jelentkezik, csak a programot szerencsélteti vele. A fullos (audio+video) streamek viszont normális sebességgel jönnek le a programnak, ugyanúgy, ahogy bármelyik másik tool-nak. Úgyhogy lövésem sincs miért csinálja.
  • A program csak letölti a két stream-et, de nem merge-eli össze, míg pl. a youtube-dl igen. (Nyilván, ha valakinek külön kellenek, annak direkt jó, de az letöltheti őket a nem kombinált verzióknál is.) A fullos stream-eknél értelemszerűen ilyen probléma nincs.

Éppen ezért a playerrel ellentétben, ahol a direct link a default, itt az original link az.

- A Formats downloader opció megújult: innentől nem a -F flag-gel operál, a stdout-ra kiköpetve az előre legyártott táblát, hanem a --write-info-json-val lementeti fájlba, aminek köszönhetően innentől itt is van {TARGET} template (prefixálandó az '-o ' flag-gel a parancssorban). Így a program egységes listát fog adni akkor is, ha belsőleg kezeli a minőséglistát, meg akkor is, ha külső tool-lal teszi.

- Az újonnan indított instance visszajelzéseket kap a primary instance-tól (többek közt a PID-et).

- Ctrl + PgDn/PgUp gombokkal lehet előre-hátra váltogatni a tabok között.

- A youtube-dl-t innentől az /usr/local/bin-ben is keresni fogja első induláskor.

Bugfixek:
- Ctrl + Space-szel többször is el lehetett indítani egy tabon a lejátszást.
- Pár apróság, ami menetközben fixálódott (pl. a külső tool-ok kezelésében egy-két dolog, na, ezért jó, hogy támogatni kezdtem az OpenBSD-t), de már elfelejtettem őket...

Egyéb megjegyzések:
- OpenBSD alatt még mindig nem működik semmilyen internal HTTP query (nem rajtam múlik: a mai napig nem érkezett semmilyen reakció a fórumtopicomra), szóval ott továbbra is maradnak a külső tool-ok.
- Sok parancssori beállítás megváltozott, új template-ek, stb; aki akarja, a manuallal felfegyverkezve kézzel is belepakolhatgatja őket a helyükre, de én inkább azt javaslom, hogy exportálják a könyvjelzőket, feketelistát, global playlistet, aztán backupolják a program configdirjét (mv ~/.ytfe ~/.ytfe.bak), indítsák el a programot és hagyják, hogy a program mindent belőjön. Aztán lehet beimportálni az előbb exportált cuccokat. És ha volt valami beállítás, (pl. extra parancssori flag-ek a playereknél, vagy akármi), akkor azt ki lehet szedni a régi backup dir-ből.

Letöltések:
- FreeBSD AMD64
- Linux AMD64
- Linux i686
- OpenBSD AMD64
- Solaris AMD64
- Manual
- Online manual
(Az SHA1 ellenőrzőösszegeket a letöltőoldalon kiírja a rendszer.)

Ugyanitt Mac Mini 2009-es kerestetik, hogy buildelhessek OSX verizót is. (Mindegy, hogy early, vagy late, csak legyen benne 2 GB RAM, hogy fusson rajta a 10.11.)

Hozzászólások

Vannak már ikonok vagy még mindig karakteres az egész?

Az elmélet az, amikor mindent ismerünk, de semmi nem működik. A gyakorlat az, amikor minden működik, de senki nem tudja, miért.

Certre nézz rá ott ahonnan a képek jönnek.

Nem tudok, nem saját, a t-hosting.hu adja a sajátját. Nekem csak egy db. FTP hozzáférésem van, más nincs. Let's Encryptet sem tudok beállítani.

Egyébként most direkt kipróbáltam PaleMoon-ból Ungoogled Chromium-ból, IceWeasel-UXP-ből, Otter Browser-ből, Midori 0.5-ből és QupZillából. Mindben megjelentek a képek, nem csak a Classic Operában. (Sőt még Konquerorban is, csak az oldal esett szét. :P)

Úgyhogy csak a kezem tudom széttenni.

A szolgáltatás amit kaptál működésképtelen sajnos ezek szerint. Az ugyanis nem valid https forgalom hogy a felmutatott certben a subject domain és a kért domain eltér egymástól. Jogos, hogy a Firefox visszautasitja. Persze 1-2 további katt-tal megnézhető.

"PaleMoon-ból Ungoogled Chromium-ból, IceWeasel-UXP-ből, Otter Browser-ből, Midori 0.5-ből és QupZillából."

Akkor a Föld populációjának a 0,5%-a aki tudja nyitni gond nélkük, juhéjj!

> A szolgáltatás amit kaptál működésképtelen sajnos ezek szerint.

Ehhez képest egész jól megy, már vagy tizenhat éve.

> Akkor a Föld populációjának a 0,5%-a aki tudja nyitni gond nélkük, juhéjj!

Az megvan, hogy az Ungoogled Chromium az motor tekintetében ugyanaz, mint a Chromium, ami motor tekintetében ugyanaz, mint a Chrome, amit - és klónjait - a Föld populációjának usque 70%-a használ? A Safarit nem tudom, hogy hogy áll e tekintetben, de jelen pillanatban nekem úgy tűnik, hogy egyedül a newschool bugróka szarakszik a kérdést illetően, amit a Föld populációjának kevesebb, mint 4%-a használ és csökken.

A HTTPS biztonsága egy illúzió, hiányának biztonságtalansága dettó. Majd ha annyira érdekel, hogy SSL errorok vannak a képek miatt, akkor majd bekapcsolom, hogy anyázzon érte. De amúgy ki a túrót érdekel, hogy pár - beloggolás nélkül is publikusan elérhető - kép titkosítatlanul jön? Ez nem érzékeny adat. Egyébként szerintem, ha kikapcsolod a HTTPS everywhere-t, akkor nem fog többet anyázni a képek miatt. Hacsak nincs az is belőve, hogy a mixed HTTPS/HTTP-ért is anyázzon.

Én az ssl errorokat ugyanabban a kategoriában kezelem mint a compiler warningokat. Megjavitom ha már ott vagyok és tudok róla, aki meg leszarja, az igénytelen.

Ne vedd feltétlenül magadra, de ez a véleményem erről a tipusú jelenségről. Amit leirtál azzal tisztában vagyok.

> Én az ssl errorokat ugyanabban a kategoriában kezelem mint a compiler warningokat.

Ez elég szomorú, mert a kettő még távolról sem hasonlít egymásra.

> Megjavitom ha már ott vagyok és tudok róla, aki meg leszarja, az igénytelen.

Ha meg tudnám javítani, megtenném, de csak azért, hogy a biccsegés abbamaradjon, mert én személy szerint leszarom a HTTPS-vallást. Az oscomp még sütit sem tárol a gépeden; mit kéne itt titkosítani?
Az MITM riogatással meg lehet menni a devnullba kirándulni, amíg:
  a) ha gyakorlatilag bárki, akinek a certjét elfogadtad, játszhat MITM-et (internetszolgáltatók és driverek (!) előnyben),
  b) elég a hulladék key-exchange segítségével összeszedegetni a kulcsokat a crackhez,
  c) magát a HTTPS-t is törték már meg nem egyszer,
  d) az egész cert-authority és cert-credibility ökoszisztéma egy rossz vicc.

> Ne vedd feltétlenül magadra, de ez a véleményem erről a tipusú jelenségről.

Ha akarnám se vehetném magamra, hiszen - mint tisztáztuk - én nem tudom elhárítani a problémát.

> Amit leirtál azzal tisztában vagyok.

Tudni és érteni - két külön dolog. Ha értenéd is a problémát az egésszel, akkor te is leszarnád az SSL errorokat egy nem érzékeny kapcsolatnál.

> Ha már van https, akkor működjön rendesen, vagy ha - mint most - nem érzékeny az adat, ne legyen https.

Csakhogy nincs HTTPS: minden képet HTTP-vel linkeltem. A hup viszont HTTPS-en jön. (Kiloggolva is.)
Nálad vagy a letiltott mixed content miatt nincsenek képek, vagy azért, mert be van kapcsola a róka HTTPS Everywhere opciója és force-olja, hogy HTTPS-ről jöjjenek a képek, viszont a cert nem a domain nevére szól.

> Nálam nincsenek képek, meg gondolom nem kevés más usernél sem ezek miat. Ennyit próbáltam elmagyarázni.

A hiba az urak browserbeállításai között keresendő. "Ennyit próbáltam elmagyarázni."

Bocsánat, kissé álmos fejjel kommentálgattam, valóban, az én oldalamon van a http átkényszeritése https -re. A szolgáltatódnak viszont megvan az a hibája, hogy másik site-hoz tartozó certet mutat fel a vhostodra, vagyis rosszul van konfigurálva. Értem én hogy nem hiszel az ssl-mániában és igaz érveket is hozol fel, de ha már ssl -t nyitunk akkor vagy működjön vagy tiltson, a féligmeddig működős ssl rosszabb, mint a semilyen.

Az egy másik dimenzió, hogy ez kinek a hibája. Az meg az én hibám/nyűgöm, hogy az error ssl -t tiltja a firefox. De a hiba ettől még létezik a site-on, és javitani kellene (szerintem).

Vagy esetleg másik infrát használni, végtelen lehetőség van három sajtburger árától felfelé havonta.

> Értem én hogy nem hiszel az ssl-mániában és igaz érveket is hozol fel, de ha már ssl -t nyitunk akkor vagy működjön vagy tiltson, a féligmeddig működős ssl rosszabb, mint a semilyen.

1. Teljesen mindegy, hogy miben hiszek (semmiben se); megmondtam: ha ki tudnám javítani, megtenném, hogy a lamentálás abbafejeződjön.
2. Ki nyitott SSL-t, mi ez a többes szám? Az oscomp mindig is HTTP-n működött, most is beírod és megy; én is úgy linkeltem be a képeket. SSL-t itt te nyitottál, pontosabban a biztonságoskodó browsered.
3. Ki tiltson? Az oscomp? Mit tiltson? Hogy kinyisd HTTPS-en? Miért tiltanám meg, ha valakinek ez a perverziója? Azért, mert nálad mindent kényszeredetten átirányít a browser? Azért mert neked nem tetszik? (Az egyébként megvan, hogy ha az oscomp tiltaná a HTTPS accesst, attól még nálad ugyanúgy nem lesznek képek, ha a rókád tiltja a mixed contentet, vagy kikényszeríti a - frissiben letiltott - HTTPS-t?)

> Az egy másik dimenzió, hogy ez kinek a hibája.

bilgécé, mint minden más is. Azoké, akik elhitették a világgal, hogy ez a koncepcionálisan törött "biztonsági" (ROFL) ökoszisztéma majd jól megvédi őket a saját hülyeségüktől.

> De a hiba ettől még létezik a site-on, és javitani kellene (szerintem).

Most írom harmadjára, hogy megtenném, ha tehetném és ötödjére, hogy nem férek hozzá.

> Vagy esetleg másik infrát használni, végtelen lehetőség van három sajtburger árától felfelé havonta.

Ez haveri alapon megy itt. Anno csináltam nekik pár dolgot és felajánlották, hogy lehet az oscomp és a BGAFC ingyen náluk. Nekem tökéletesen megfelel.

Úgy látszik egyikünk se szereti ha a másiké az utolsó szó :))

A site hibásan működik, mert a helyes viselkedés a 443-on érkező SSL/HTTP kérés tiltása lenne, vagy korrekt kiszolgálása.

De értem, hogy nem a te hibád (ezért is utaltam rá, hogy válts szolgáltatót). Tekitsük ezt barátságos hibajelentésnek, aztán lépjünk tovább, mert már fárasztó ugyanazt ismételni, neked is meg nekem is.

Nem, csak már a púpom tele van vele, hogy a programról szó nem esik, de már az egész topic a kutyát nem érdeklő cert errorral van tele.

A "site" az a weboldal, annak köze nincs a protokollhoz, amin keresztül hozzáférsz. Taknyoljam tán bele PHP-be, hogy ha a port a 443-as, akkor irányítson át HTTP-re? Az a te HTTPS-t kikényszerítő browsereddel egy gyönyörű végtelen redirectet eredményezne... Vagy ne redirecteljen, csak írja ki, hogy a HTTPS nem engedélyezett? A júzer meg nézzen, hogy hát mi az, hogy nem engedélyezett, hát ez a lap, amire ez ki van írva, az is HTTPS-en jött le... És ugye ez csak a PHP-ból elérhető tartalmakra vonatkozik, a közvetlen fájlok (képek, egyebek) ugyanúgy elérhetőek maradnának. (Nem, nincs .htaccess.)
És ez még mindig csak szerinted hibás viselkedés; kérdem még egyszer: az megvan, hogyha tiltaná a HTTPS-t, akkor se lennének nálad képek? Így legalább a bugrókán kívüli júzerek hozzá tudnak férni a tartalomhoz...

Hát elég fárasztó, főleg, mivel amiket te leírtál indoklásnak, hogy ez miért "hiba", azokat én N-felől cáfoltam már, te meg csak annyit bírsz visszaírni, hogy te érted, de ez akkor is hiba. Szerinted. Szerintem meg a HTTPS ökoszisztéma létezése maga a hiba. Szolgáltatót meg nem váltok. Nekem jó itt. Főleg ingyen.

Közben kijött az 1.5.1, mert a tecső megörvendeztetett egy újabb parse-álnivalóval, belefutottam egy bugba is és kapott egy kis refaktort, akkor már. A linkek ugyanúgy működnek.