MPlayer 1.0rc3 - "Godot has arrived"

 ( trey | 2010. május 30., vasárnap - 18:36 )

2007. október 7-én jelent meg az MPlayer 1.0 második kiadásra jelölt verziója. Az rc3-ra több mint két és fél évet kellett várni, de végül ma megérkezett.

Az rc3 eredetileg egy évvel ezelőtt érkezett volna, így már azelőtt elavult, hogy kiadták volna. Disztróknak feltehetően hasznos lesz ez a kiadás, de a bejelentés szerint általános felhasználásra jobban megfelelnek az aktuális Subversion snapshot-ok. Részletek a bejelentésben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Godot has arrived" - ezen hangosan felsikitottam :D

+1
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

"általános felhasználásra jobban megfelelnek az aktuális Subversion snapshot-ok"
Akkor mi az értelme a release-nek egyáltalán? :-)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

mert a release-t talán - de csak talán - le is lehet fordítani:)

Nekem a git-es verzioval se volt gondom, mindig fordult. (Na jo annyi hibat hany hogy csak porog a terminal de mukodik...)

az x264el mindig bajom van. 'anélkül meg nem élet a élet'

Nem egyszerűbb akkor csak valami COMPILES taget csinálni, és azt rakosgatni arra, ami lefordul? :-P


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

anno voltak olyan featurek amik annyira bugosak/felkeszek voltak, hogy nem volt alapbol bekapcsolva. de release-be bekapcsoltuk, hogy teszteljek a juzerek.

mostani rls szerintem user/distrokeszito nyomasara lett kiadva a sok "miko' lesz ma' rillizzz???" miatt. nem hiszem, hogy (sokban) elter az aktualis svn-tol.

A'rpi

"anno voltak olyan featurek amik annyira bugosak/felkeszek voltak, hogy nem volt alapbol bekapcsolva. de release-be bekapcsoltuk, hogy teszteljek a juzerek."

Ez igy elsore elolvasva nagyon rosszul hangzik. Ize, a gond az, hogy masodikra is.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

tudom, es elarulom, hogy harmadikra is. de az userek nem voltak hajlandok cvs/beta verziokat megnezni, tesztelni, meg ha az o altaluk reportolt bugokat javitottuk benne akkor se, csak a rendes releaseket. igy alakult ki, hogy a cvs snapshot a stabil, es a release a beta :)

A'rpi

lol, ilyen se volt meg, hogy mplayer rls-rol a hup-on ertesuljek eloszor ;)

azert tervezik mar 1 ideje:
- rc3: "BikeshedCounter" March 27, 2009
+ rc3: "BikeshedCounter AKA Godot" May 30, 2010

hmm, ez kezd erdekes lenni:
Date: Fri Mar 27 20:13:50 2009
New Revision: 29073
Log:
Create 1.0rc3 release branch.

szoval ez az rc3 nem is friss svn-bol van hanem tobb mint 1 eves branchbol, amibe a log szerint csak par kisebb fixet backportoltak... rotfl.

A'rpi

en is hangsoan rohogtem... csak aztan belegondoltam, hogy a disztributorok nagy resze ezt nem fogja felfogni, csak azert is pakolja a "friss" release-t a repoba majd :/
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

ah en mar regen feleadtam, es csak snapshotbol csomagolom, megha van is riliz neha

--
NetBSD - Simplicity is prerequisite for reliability

Tudom, nem vagyok hivatott a belepofázásra, de: olyan nehéz lenne egy úgy-ahogy leforduló svn-snapshotot kinevezni 1.0-nak, majd ami bug van benne, azt az 1.1-re kijavítani? Mi értelme van annak, hogy a stabil kiadás több éves állapotot takar, és a júzerek nagy része (aki simán a csomagkezelőből telepíti) ezt használja?

talan az, hogy ugy fejlodik egy projekt, ahogy 2010-ben fejlodnie kell, es nincs bezarva fejlesztest (vagy akar bugfixeket) akadalyozo felesleges freeze-ek koze? Es mplayernel nem "ugyahogylefordulo" snapshot van, hanem a topbbi ilyesmi projekttel ellentetben a kommitokat tudtommal tesztelik 2-3 napig, mielott bekerul svnbe. Nem az mplayernek kene maskepp gondolkodnia, hanem a disz tributoroknak
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

honorshark, te vagy az, csak a masik loginnel?
___
info

megfigyelhetted mar, hogy honorsharkkal tobbmidnenben nem ertettunk egyet :D Bar az mplayeres dolgokban asszem igen
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

"Nem az mplayernek kene maskepp gondolkodnia, hanem a disz tributoroknak"

Ez itt nem gondolkodás, inkább kommunikáció kérdése. A "release", az "unstable", a "snapshot" olyan fogalmak, amikkel a fejlesztők és a disztró csomagolói egymással kommunikálni képesek. Az mplayernél úgy tűnik máshogy értelmezik ezeket (pl "a kommitokat tudtommal tesztelik 2-3 napig, mielott bekerul svnbe", a release pedig nem cél, hanem "akadályozó és felesleges"). Miért változtasson a gyakorlatán egy disztribúció, ha egyszer a többi 5232 csomagnál jól működik a stable-unstable megkülönböztetés? Mi lenne a helyes teendő? Az Ubuntu 10.04-be a 20100420-as svn kerüljön bele? Vagy a 20100422?

minden 3 naponta a másik :-)

epp most kerult elo megin ez a tema, erdemes az egesz threadet elolvansi:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/089643.html

A'rpi

igen, ha az Archnal es a Mintnel es a Slackware-nel tudnak egy ilyen minimalis figyelmet szenteléni a fejlesztok velemenyere, akkor az Ubuntutol is elvarom
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Egyszerű:
x db csomagnál még van rá ésszerű emberi kapacitás (slack, arch)
x*100 db csomagnál már hihetetlen nagy feladat lenne (debian, ubuntu)

Azert tegyuk hozza, hogy az x*100 -t nyugodtan le lehet osztani n db architekturaval es y darab csomagdarabkaval, mert ahany fele szetszedik a csomagokat a debillanyek, az szepen meg tudja dobni a darabszamot.

----------------
Lvl86 Troll

Nagyon sokáig magam fordítottam az svn-t, de azért most már belátom, hogy sokaknak tényleg opció az svn használata. Meg egy stabilnak szánt rendszerre sem lehet csak úgy nem támogatott repókat felrakni, mert súlyos kockázatnak tesszük ki a rendszert.

Egyébként nem panaszkodom, hiszen ingyen van, lelkesedésből fejlesztik. Csak rossznak tartom, hogy a felhasználók többsége 2-3 éves állapotából ítéli meg az MPlayert, mert nincs ideje, lehetősége másra. Gondolok itt a DVD-menük lejátszására, ami azért nemrég került bele...

Ugyanez a véleményem a wine projektről is. De ők legalább most végre megjelentetik a wine-1.2-t. Előtte ott is két évig a disztrókban ősrégi változat volt, miközben az instabilból már régen lehetett volna új release-t csinálni.

Ezt igy most gondold ujra. Kulonbozo meretu projektekrol beszelunk.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nekem csak egy naiv kérdésem lenne: milyen ütemben halad az MPlayer fejlesztése? Látszólag az MPlayer háza táján elég nagy csönd honol, kívülállóként nem igazán látom az aktivitást. A lassú kiadási ütemterv nem is zavarna, nincs is semmilyen problémám, egyszerűen csak nem igazán követem a háttérben történő eseményeket, pusztán kíváncsiság vezérli kérdésem.

(Már csak azért is, mert nem igazán találok egy rendes lejátszót. VLC majdnem jó lenne, de annyira bugos és sok vele a probléma, hogy lassan az idegeimre megy. Alap MPlayer felületileg kicsit puritán, a ráépülő frontendekkel (pl.: SMPlayer) viszont nagyon szimpatikus lenne, de valamiért egyik sem az igazi. :/ Ha valaki tud ajánlhatna valamit.)

linuxra right click open with mplayer, midnenfele gui nelkul. Se kmplayer se smplayer se gnome-mplayer se semmi ilyesmi nem valt be, mplayer az nekem "parancssoros" lejatszo marad. Ezt a disztributoroknak probalhatod elpofazni, még a Debian meg a Suse sem kepes GUI-mentes mplayert szallitani, ami még egy ujabb ok arra, hogy forrasbol forditsd a latest snapshotot (kiveve Archon, Minten meg Slacken, ott svn-est szallitjak).

Az mplayer az a projekt, ahol annak ellenere, hogy nincsenek release-ek, annak elenere igenis megy a fejlesztes, mar Inteles meg Atis hardware gyorsitas commitok is voltak, mig a xine még a vdpau implementalasaval is kuszkodik azota is. Az mplayer a legjobb pelda arra, hogy mennyivel jol is tud fejlodni egy rolling projekt valojaban. Ennek ellenere pl kernelbol vagy KDE-bol nem orulnek ilyen szintu rolling release-nek, de egy filmlejatszonal tenyleg eleg a commitot 2-3 napig tesztelni
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

+1
Feliratok tologatására, feliratok váltogatására, vdpau gyorsításra, av-sync beállítására (MPEG-TS-nél kell, sajna) az mplayer-nogui a legjobb.
Nekem egy újabb változat van, mint ami a lucid tárolóba bekerült (Version: 3:1.0~rc3+git20100526.98a8126-0ubuntu1~ripps1~lucid), ez gyorsabb.
Az állandó dolgokat meg config fájlban rögzítettem.

Egyedül a DVB-re nem tudok jó megoldást, mert a HD-t tök jól lenyomja, de az SD-knél baj van a -mc paraméterrel, így ezeket a VLC-vel szoktam nézni.
Rögzíteni is mplayer-rel szoktam (dumpstream), ami egyben timeshift-re is lehetőséget biztosít. Számomra megfelel.
A legnagyobb bajom az, hogy az ffdshow-hoz hasonló, elég szerteágazó postprocessing nincs még a vdpau alá rakva, de az idő talán majd ezt is megoldja.

[athuzas]majd a kovetkezo release-ben[/athuzas] barmelyik nap belekerulhet :D
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Ami at van huzva, az "s" bbcode taggel van csinalva
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

multkor neztem sourceban, de utana vmiert nem ugy jelent meg. Most sem
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Nem html, hanem bbcode. [ s ] athuzva [ /s ], a szokozoket meg vedd ki a tagekbol.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A pp? Ez jó hír. Honnan értesülhetek róla?

Lehet, hogy rosszul csinálok valamit, de nálam még a VLC volt eddig a leghasználhatóbb. Jó, nem is zabálom úgy a filmeket, illetve nem használok egzotikus formátumokat. Eddig még azokat is játszotta, amin egy Totem, vagy egy MPlayer elhasalt.

totem egy vicc. Foleg a gstreamer alatta mint filmlejatszo backend. Xine akkor mar egy fokkal hasznalhatobb filmlejatszasra (kaffeine)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

csak ugy jonnek a baromsagok! :)

a gstreamer backend tud hasznalni libavcodecet (gyk ffmpeg), x264et is. innentol a backendre azt mondani, hogy fos, hat eros tulzas.

Amúgy gstreamer alappal sincs túl sok bajom, egy-egy dolognál van kínja, ezért is maradt default nálam a VLC (valószinűleg lustaságból). Nincs kizárva, hogy a Totem a hunyó.

> csak ugy jonnek a baromsagok! :)
es te is azt irsz! :)

libavcodec != ffmpeg. az csak 1 kis resze, amiben a codecek vannak. ezen kivul meg eleg sok minden kell egy lejatszohoz, az egyik legfontosabb (es ezen dol el a hasznalhatosaga, megbizhatosaga) a demuxerek. ez pl. az mplayerben sajat van, nem az ffmpeg-et (libavformat) hasznalja, bar azt is tudja, ha nagyon akarod. gstreamernek is sajat demuxere van, es eleg gagyi.
tovabba az audio, video output driverek, iletve az a-v szinkronizalas sem elhanyagolhato, ez is minden playerben sajat, vagy esetleg SDL-t hasznalnak.

A'rpi

tudom, irtam mar playert :) de o arra panaszkodott (vagy en ezt lattam bele), hogy "nem viszi", ott pedig a demuxer+codec dont, imho. :)

Ettol meg a gstreamer filmes backendjei elegge ratyik. Nagyon sokat kene dolgozni rajtuk, hogy egyaltalan egy lapon lehessen emliteni oket az mplayerrel. Akkor is, ha tudnak hasznalni x264-et.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

gondolom sokat programoztad, programozok gyongye.

Nem, en peldaul hasznalnam, linux userek gyongye.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

x264 mar reg mindenben van (xine, gstreamer, vlc, mplayer), szoval nem az volt a kerdes, hogy jatssza-e
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Meg jo, hogy az x264 nem h.264 dekodolasara lett kitalalva.

---
pontscho / fresh!mindworkz

Apu gépén erről nem volt info :)

[ #FreedomFlotilla ]

Nekem semmi bajom nincs vele. Eddig mindent lejatszott amit probaltam. Ezen felul nincs benne kismillio useless feature es kezelni is tok egyszeru.

gentoo stable : 1.0_rc4_p20091026-r1
gentoo testing : 1.0_rc4_p20100506

Apple MacBook C2D 2.2Ghz 2x2G Intel X3100

gentoo kulon sztamozassal el :D de legalabb nagyjabol a snapshotokat hasznalja (fixme)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Sima video megjelenítéshez mindegy mi... ami éppen lejátsza (mplayer, vlc, totem), de film nézéséhez csakis XBMC (http://xbmc.org/)
A legszimpatikusabb benne, hogy a tömörített fájlt (még ha 50 dbra tördelt) ha média akkor a tartalmát mutatja, majd röptében kicsomagolva játsza le (avi vagy akár iso -t is)
Ráadásul, ha újraindítom vagy később folytatom ugyan ott folytatja ahol abbahagytam (annak ellenére hogy tömörített fájlban van).

Lehet, hogy mlayer vagy egyéb backend van mögötte, de mint felület kiváló.

Apropó az mplayer tud tömörített állományból közvetlen lejátszani?

Minek igenytelenkedjek tomoritett vackokkal, mikor 1-2 perc mindent attolni mkv-ba.

ffmpeg van XBMC/Plex alatt. Ez utobbi raadasul ffmpeg-mt varianst tol, bar mivel a kodbazis nagyjabol azonos a ket varians kozott ezert valoszinu, hogy XBMC is igy tesz.

---
pontscho / fresh!mindworkz

pl torrenten letöltött "házi oktató" :-) filmek darabolt rar-ban vannak, s ha szeretnék visszaadni a "közösségnek" is akkor nem törlöm le a letöltött fájlokat.
Kicsomagolva és tömörítetten egyidejűleg tárolni a gépen több helyet foglal, ráadásul a kicsomagolás plusz idő amikor megnézni 1x vagy 2x fogom megnézni...felesleges.

Így, ha van mód, hogy ne kelljen kitömörítésre várni, majd lejátszani, s törölni a kitömörítettet azt örömmel venném, s megköszönném.
Nem tudom mennyi meló, de sokszor jól jönne ilyen feature (szerintem másnak is).
Ubuntuban jobbklik rar-ra, play content with mplayer ;-)

MPlayerben volt unrar támogatás valamikor.

FIXME: mire épül (Roschal-féle hivatalosra vagy az urarlib nevű abandonware-re ami 10 évnél újabb formátumot nem ismer) ill. mennyire tartják karban.

szerk:
MultimediaWiki szerint:
How can I play movie in rar?
unrar p -inul movie.part01.rar |mplayer -noidx -

sejtettem, hogy valami ilyesmivel meg lehet oldani... de ez szerintem nem 100-as...

Viszont jönnek az olyan érdekességek, hogy lehet-e seek-elni (pl az 56. percre ugorani) vagy épp ha az egy iso ami dvd akkor mit kezd vele...

DVD esetén gondolom (...)|mplayer dvd:// -dvd-device -

VLC tud benne seekelni? Hogy csinálja?

xbmc-re írtam, hogy tudja... vlc-t nem tudom.
Az XBMC beépített filetallozójában, amikor olyan mappába lépek be ahol tömörített darabolt fájlok -akár rar akár zip- van, aminek a tartalma iso vagy avi (vagy egyéb media), akkor már eleve csak a médiát látom "elrejti" a sok felesleges állományt (nfo, sfv, tömörített fájlok) és egyszerűen csak rábökök hogy megnyit...
- lehet benne seekelni,
- dvd-nél chapterekre ugrani stb
- nem kell várni a kitömörítésre egyből játsza (2-10 sec delay max lehet de elhanyagolható) .

Azt hogy milyen megoldással csinálja nem tudom, Pontscho biztos tudja.

szerk: félreolvastam, tárgytalan. ("lehet benne seekelni" - ez viszont érdekel :) )

Igy mar valamelyest jogos, de meg igy is megkerulheto a kerdes siman. :)

---
pontscho / fresh!mindworkz

nem is azért írtam :-) hanem inkább saját tapasztalatomat írtam le, hogy milyen apróság miatt döntöttem egyik vagy másik mellett... (még úgy is hogy nagyságrendekkel több memóriát igényel, s indulási idő is több valamint robosztusabb kezelőfelülete van, de megszokható...)

Amúgy előtte csakis mplayer-t használtam Ubuntu és Windows-on egyaránt.
Így is amikor csúszik a felirat vagy épp hang akkor marad a kicsomagol és mplayer, mert lehet billentyűkkel szinkronba hozni lejátszás közben, ami szuper dolog :-)

azt nem értem ez miért a lejátszó dolga lenne

a windows is nehezen kezeli még a zipet is, hiába olyan mintha mappa lenne, mégis szív vele az ember ha nem tudja hogy az biza zip (pl egy fájlt egy program megnyit, az már nem látja a következőt, pedig csak olvasható igazi mappa ként nem lenne vele gond)

azaz a fájlrendszerre kellene valami, mint ahogy az iso-t win és linux alatt is kényelmesen fel lehet csatolni, de a zip-et és a többi tömörített pedig még csak nem is láttam

(ps: azt értem hogy "solid" esetben nehéz lenne seekelni, de pl zipnél megoldható lenne és solid esetben is opcionálisan pl egyszer temp-be kitömörtené.. )

valóban... jól hangzik, bár az iso egy fs kontainer a zip pedig tömörített...
Gondolom fuse-n keresztül létezhet "zipfs" :-) csak kérdés, hogy mennyire működőképes...
Lehet, hogy az XBMC is ilyesmit csinál, hiszen beépített filemanager-e van ami akár meghívhatja így is, ennyire nem ismerem.

Ez a darabolt rar egy idiotasag, dunaba kene loni az osszeset, aki igy tesz ki dolgokat. 2010-ben mar senki nem torrentezik olyan fajlrendszerrol, ami nem kepes 4G-t eltarolni egy fajlban. Es nehogy mar a filmlejatszo alkalmazkodjon minden hulyeseghez.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az elsődleges warez elosztók FTP serverek, úgyhogy az őskövület protokollal ~egyidős filedarabolós baromságnak sajnos ott van létjogosultsága. Aki meg nagyban seedel, direktben lehúzza, aztán azt dobja fel torrentre egy az egyben...

WTF? Melyik normalisabb FTP szerver nem tud elkezelni 4G-s fajlokat?
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A 64 bites file offset (4 GB feletti fileok) támogatása még 2007-ben is probléma volt 32 bites rendszereken, az akkori disztribúciók általában letiltották a serverek akkoriban kísérleti largefile opcióját fordításnál.
Tehát a filerendszeren megvolt a nagy file, de se ftp-n, se http-n, se smb-n nem tudtad szolgáltatni a daemonok kézi újrafordítása (és kockázatvállalás) nélkül.

A másik gond az átviteli hiba, ami miatt az egészet kitalálták még a floppy korszakban. Azért daraboltak, hogy ha valamelyik rész hibásan jön át, ne kelljen újra letölteni az egészet.

szerk: kicsit átírtam, jobban körbenéztem, nem akarok FUD-olni

Hmm... ennyire nem vagyok otthon a warezbe, szoval akkor megkovetlek.

Ez esetben a torrentfeltoltok a hibasak, hogy nem egyesitik a fajlokat megosztas elott. Meg mindig ugy gondolom, hogy ne a lejatszo idomuljon az ilyesmihez.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Releasse-t nem illik megváltoztatni, ha felrakjuk máshova. Kifejezetten tapló dolog arrafelé AFAIK.


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Érdekes, ez FreeBSD-n már tíz éve sem volt probléma...


suckIT szopás minden nap! Adobe vallás

Azzal nem élek. Viszont Debianon sz.ptam vele eleget...
Apache-ban amúgy a 64 bites offset csak 2.2-től default 32 biten, 2.0-nál configure opcióval lehetett bekapcsolni (amit a debian/redhat nem tett meg), azelőtt meg nem támogatták a fő forrásban. A FreeBSD saját patchet tartott karban?

Az FTP servereknél, sambánál hasonló volt a "törzsfejlődés" az elmúlt években... szerk: a kernel is csak valamelyik 2.2.x verzió óta támogatja.

joh, hat BSD-n large file ismeretlen fogalom :)

--
NetBSD - Simplicity is prerequisite for reliability

a warez scene eleg speci cuccokat hasznal, nem kedvenc bubuntutok alapftpdjet:(

Eleg speci lehet, ha nem tud elkezelni 4G-t egy fajlban...
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

ott ez nem szempont, minden darabolva van. ez csak a lugban szamit, max.

Akkor probalj meg raguglizni a "bittorrent streaming" kulcsszavakra, es probald meg osszehozni a darabolt fajlokkal.

Nem is tudom, hogy amit csinalsz az rohelyes, szanalmas, vagy csak megint elgurult a gyogyszered. De lehet, hogy edzodnom kell, most egy honapig HUP-mentes helyen voltam.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

mire gondolsz pontosan? hogy a warez scene az nem a bittorentes pistikekrol szol? vagy ezt nem tudtad?
lehet elobb streameltem elosztott rendszerrel videot, mint Te...

ha baromsagokat hordasz ossze-vissza olyanrol, amihez nyilvanvaloan nem ertesz, legalabb ne nezz le mast, amiert o tobbet tud errol, hanem maradj legyszi a sarokban, csondben.

Hat, a stilusodon lenne meg mit csiszolni, ez teny, de legalabb haladunk valamerre.

Egyebkent meg elhiszem, hogy elobb streameltel elosztott rendszerrel, mint en, kerdes, hogy darabolt fajlokbol is tudtal-e streamelni. Mert tulajdonkepp ez itt a lenyeg, egy release-t nem valtoztathatsz meg (= nem csomagolhatod ki), eredeti (= becsomagolt) allapotaban viszont nem lehet streamelni. Illetve lehet, hogy meg lehet oldani, de eleg problematikus, es sok munkat igenyel.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

a stilusom olyan amilyen. nem kell erte szeretni.

arra probaltam ravilagitani - sikertelenul -, hogy senki nem akar ilyen releasekbol streamelni. altalaban az a cuccok utja, hogy (ftp szerverek)+[0] -> torrent oldalak. en lattam mar olyan torrent oldalt (tavolrol;)), ahol kicsomagolva raktak fel a dolgokat, de ez ritkasag.

[0]: a + jel a tranzitiv lezart

Az ilyen releasekbol valoban senki nem akar streamelni, nyilvan, mert nem is tud. Azonban a nagyon jo minosegu release-k sokszor ilyen formatumban kerulnek kiadasra, amit viszont jo lenne streamelni - de nem lehet. En pedig erre a problemara probaltam ravilagitani.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

nem a 4G miatt vannak darabolva. de amugy a 4G is probelma lehet, mert az ftp protokollban nem definialjak, sot mar 2GB folott gond van a legtobb ftp _klienssel_ (sok wines szar, de mc se jobb), amikor folytatni kell egy mexakadt letoltest.

a darabolas egyebkent eredetileg a torrent es tarsai szimulacioja miatt volt anno, csak warez sceneben racelesnek hivjak, elkezdi valaki tolteni a rar-okat es kozbe mas szerverekrol is toltik a tobbi filet. igy a cucc kulonbozo darabjai kulonbozo szerverekrol jonnek, epp ugy mint a torrentnel. ha valamelyik rar hibas (crc nem stimmel az sfv fileban) akkor azt ujratoltik mashonnan. a vegen lehet sfv alapjan ellenorizni (kb mint a hash ellenorzes torrentben).

az, hogy a p2p (torrent) es az ftp scene elegge 2 kulon mufaj ma is, es gyulolik is egymast, na meg akik a 2 kozott tradelnek, nem beszleve az eltero release szabalyokrol, az mar mas kerdes, es itt elegge offtopik.

A'rpi

Annál nincs rosszabb, mint torrenten látni az eredetileg FTP-re készült, ezért tömörített-darabolt fájlokat.
Nem beszélve arról, hogy torrenten elég elterjedt trükközés a RARos darabolás, ami XY weboldalról szedhető kóddal nyílik. Az ilyet bottal nem piszkálom meg, mindig ellenőrzöm az első r00 alapján.

Másik örök kedvenc a "szedj le xyz.exe-t a lejátszáshoz"...

Ize... nem reg volt valami os valami fs-sel ahol eloszeretettel korruptolt az adat. Vagymi. :)

---
pontscho / fresh!mindworkz

Vagy inkabb a wares scene szokjon le errol a mult szazadi 56k-s korszakot idezo baromsagrol.

----------------
Lvl86 Troll

+1
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Első nekifutásra egész kényelmes. Azt esetleg meg tudod mondani, hol tudok az adott filmhez feliratot betölteni?

ugyan olyan nevű srt vagy sub-nak kell lennie mellette (tömörített fájlok esetén is csak a rar-ok mellett) és autómatikusan betölti...

GUI-nal van ra menupont, CLI eseteben pedig azt hiszem, -sub opcio.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

egy olyan mellekkerdesem lenne, hogy az svn snapshot mission nelkul elfordul minden architekturara? (elsosorban arm-ra kerdezem)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Probald ki. Ha nem jon ossze, probalj meg elozo rev-et. Nezz meg egy arm-os distrot (pl debian sid, arm), es hogy melyik svn van epp. Aztan azt hasznald. (bar git-eznek nem svn-eznek)