YTFE

[tch]

A kugli megint variálhatott valamit a trutymócipherében, mert qjs-sel megint throttle van. nodejs-sel működik.

[janugsa]

Megnéztem. Én a lejátszó pufferelésén veszem észre. 360p-nél jó, 720p-nél már a pufferelést utoléri a lejátszó és leáll, szaggat, akadozik. A qjs-t használtam.
Kipróbáltam nodejs használatával is, azon jó minden.
Végső esetben ott van az „original“ gomb, azaz yt-dlp használata.

[tch]

Igen, direkt benne hagytam a lehetőséget, de szerencsére nodejs-sel még mennek az internal linkek, mert az original URL-s via yt-dlp sokkal lassabb (a Python "cold-start" miatt). A qjs-sel nem tudok mit kezdeni. Már írtam a készítőjének a múltkor, de nem igazán foglalkoztatja a probléma, azt is én oldottam meg helyette, hogy a non-standard dátumokat megegye. Nem tudom, hogy jelen pillanatban épp mi miatt nem megy qjs-sel, mert lövésem sincs, hogy a qjs mit nem támogat még a non-standard dátumokon kívül...

Ha van más parancssori JS interpreter, azzal is lehet kísérletezni, nem csak ezzel a kettővel megy, hanem bármelyikkel (amelyik tudja futtatni a kugli féle trutymóciphert).

[tch]

Viszont közben eszembe jutott valami: a non-standard dátumok parse-álásának egyik problémája, hogy az időzónák rövidítései között több ütközés is van:
https://en.wikipedia.org/wiki/List_of_t ... reviations
Lehet, hogy most van a felsorolt dátumok közt egy olyan, aminek az időzónájának rövidítése ütközik egy másikkal, a kugli meg a másikra "gondolt". Ez viszont azt jelenti, hogy a player következő cseréjénél ez megoldódik és megint menni fog qjs-sel is.

De ez csak tipp.

[tch]

Viszont menetközben belefutottam abba, hogy a kugli bizonyos userek csatornáit máshogy adja oda, mint eddig és nem jelennek meg a videók. Ezt kifixáltam (pár egyéb apróbb hibajavítás is került bele), frissítettem a doksit és akkor elérhető az 1.18.0 az oscompon. Benne van ez a perzisztens kapcsolat opció is, bár itt nem mértünk vele gyorsulást, de talán van olyan lassú gép, ahol segít valamit.

[tch]

A kugli elkezdte tolni ezt a "kukacos" csatorna URL-t, amit a YTFE nem ismert. 1.18.2 elérhető az oscompon. (Közben volt egy 1.18.1-es is, benne három jelentéktelen bugfix-szel, amibe nem hiszem, hogy bárki belefutott volna rajtam kívül...már nem is emlékszem, mik voltak.)

[janugsa]

Az YTFE erőssége, hogy nem hagyományos módon oldja meg a „dekodolást“, ezáltal a leggyorsabb.
Az YTFE tudja kezelni a youtube-dl és az yt-dlp megoldást is, de ezekkel lassabb.
Most 2023. 02 hónapban variálták mindkettőt. Ezért próbáltam ki őket.
Youtube-dl használatához python 2.6 kell minimum. Yt-dlp működéséhez python 3.7 a minimum, YTFE -hez nem kell python, igaz kell külsős JS interpreter ( én a node.js használom), de ezt puppy-ban könnyebb telepíteni mint egy python-t.
youtube-dl mérete 1.8MB
https://github.com/ytdl-patched/youtube ... ses/latest
yt-dlp mérete 2.6 MB
https://github.com/yt-dlp/yt-dlp/releases
Valamelyiket helyezzük el a usr/local/bin mappába, nem árt szimlinkelni a root/bin mappába mert néhány más program például smtube ott keresi.
YTFE-ben az Direct -ami az ytfe, vagy a Original --ami az yt-dlp/youtube-dl .
YTFE-ben az átváltás a jobb felső sarokban az „Original.....“ vagy átváltás után „Direct...“
feliratra kattintva lehet. Vagy a Prefs ikon majd a Tools és ott lejátszásra illetve felvételre
vonatkoztatva is megtaláljuk az „Original“ vagy a „Direct...“ választási lehetőséget.
Leggyorsabban a videó a „Direct..“ beállítással indul el 2-5 sec, utána az yt-dlp 6-10 sec,
végül a youtube-dl 12-16 sec. Régi 2 magos laptopon vizsgáltam.

Milyen python van a puppy-ban, konzolba írni:
python --version
ez a 2-es verzió számát mondja meg.

python3 --version
ez a 3-as verzióról ad információt.

[tch]

A direct opció azért gyorsabb a többinél, mert a YTFE olyankor play esetén már a kibányászott, konkrét streamlinkeket adja át a playernek, azt ugyanis nem a play gombra kattintáskor bányássza ki, hanem a YT page megnyitásakor. Ezzel szemben, ha külső tool (yt-dlp, youtube-dl) használatával játssza le a videót, akkor a külső downloadernek akkor, a play-re kattintáskor kell letöltenie a YT page-et és kibányásznia belőle a linkeket és átadnia a playernek. (Az már más kérdés, hogy a page letöltése és a linkek kibányászása is sokkal gyorsabb YTFE-ben, mert ott egy gépi kódú, már futó program csinálja ezt és nem egy VM-ben futó script, ahol el kell indítani a VM-et, parse-álni és interpretálni a scriptet, etc.; a Python "hidegindítás" nagyon lassú...)

A külsős JS-interpreter függőség nem fog örökké tartani; keresek egy olyan JS interpretert, amit be lehet ágyazni a programba és el is bír a YT trutymócipherével. Sajnos a qjs e-téren kudarcot vallott, de vannak még más JS interpreterek is. Természetesen, miután lesz beépített, hogy ne kelljen a külsős, attól még a lehetőség meg fog maradni, lesz fallback, ha a google megint olyan taknyolásokat csinál, amit már megint csak a Blink-es node.js tud majd megemészteni. Sajnos a google gőzerővel dolgozik a YT Chrome-only-vá tételén.

[tch]

Felraktam az 1.18.4-et, benne két bugfix-szel, amik a betöltésnél leakasztották a tabot, rosszabb esetben a programot, ha a csatornáknál vagy a videóknál a lista nem létezett.

Közben volt egy 1.18.3 is, egy enkapszulációs glitch fix-szével (a videoplayer fejlécében az aposztrófok eltűntek a videó nevéből), egy a HTML parserben lévő bug fix-szével, a description a kugli taknyolása miatt hol így, hol úgy volt tárolva és az új tárolást a YTFE nem ismerte, illetve a 'mujs' nevű interpretert hozzáadtam a keresendő JS interpreterek listájához.

[janugsa]

Nálam a 64 gtk2 és a 64 QT5 jó , mind a 1.18.3 és a 1.18.4.
De a 32 bites gtk2 nem jó, sem az 1.18.3 sem a 1.18.4.
Beállítás jó, keresés jó, de a lejátszás elindításakor lefagy. Szinte mindig.
Ha LXTerminallal indítom el ezt írja ki lefagyásnál:

Képenyő kép(2).jpg (46.3 KiB) Megtekintve 731 alkalommal

Feladatkezelővel tudom csak "kilőni" annyira lefagy.
Itt a log fájl:

ytfe.log.gz

(31.36 KiB) Letöltve 30 alkalommal.