próbáld ki ezt a Hadu.ini-ben a [Serv_szerveredneve] résznél:
PrioCAIDProv=0123:ABCDEF,4567:89ABCD
; PrioCAIDProv= ; [None], or 32 max entries of CAID/Providers for priority
Sok sikert! :) Ez így van, és sok olyan dolog, ami (még?) nincsen kihasználva.
Van egy olyan érzésem, hogy a fejlesztők nem ismerik rendesen a mount parancs paraméterezését
vagy
korábban loop eszközökkel dolgoztak (azért ezek a nagy fájlok, de akkor miért üresek?!) és nem jól írták át a paraméterezést
vagy
egyszerűen csak tele akarták pakolni a flash memóriát
nagyon tönkretenni nem fogod tudni, legalábbis addig biztosan nem, amíg van telnet meg ftp :D
a fő rendszerindító script az /etc/inittab szerint:
# main rc script
::sysinit:/etc/init.d/rcS
szóval az rcS fájlt kell nézegetni.
viszont a /etc meg a /etc.img-ből tömörítődik ki (a /var ugyanígy), amely igazából egy sima .tar fájl, szintén egy tmpfs-re. jó lenne megtudni, hogy mi csinálja meg a kitömörítést.
közben rájöttem, hogy a /home az cramfs (azaz compressed ram fs) és ezért nem írható!
ahhoz, hogy az előbbi varázslásokat elvégezzük, valahogyan jffs2-re kellene formázni a /home-ot, vagyis a /dev/mtdblock2-t..., úgy mint a /data-t (/dev/mtdblock4)
Igen, lehet azt is, ez a 2. módszer.
A /home-ban van egy mountapp.sh script, ami annyit csinál, hogy:
#egy teljesen üres 34960 kbyte méretű fájlt csatol fel /app-nak, 777-es joga lesz a /app-nak, a -n meg azért kell, mert a /etc írásvédett (bővebben man mount)
mount -nt tmpfs -o size=34960k,mode=777 /home/tmpfsapp.img /app
#várakozik (kell ez?)
wait
kicsomagolja a /home/isapp.bin.tgz tartalmát a /app-ba
tar -zxf /home/isapp.bin.tgz -C /app
wait
Tudtommal ahhoz, hogy egy memóriabeli ideiglenes fájlrendszert (tmpfs) csatoljunk fel, csak a méretet kell megadni + az útvonalat, tehát ez a majdnem 36 megabájtos csak 00-kkal teli fájl törölhető lenne (ekkor viszont át kell egy kicsit írni a tmpfs-es sort) pl.
mount -nt tmpfs -o size=34960k,mode=777 tmpfs /app
Innentől kezdve van elég hely, hogy bármit felmásoljunk a /home-ba, akár a háttérképet és a mountapp.sh-t is kiegészítheted a háttérkép bemásolásával.
igazából azt kell csinálni, hogy ftp-n keresztül letöltöd a /home/isapp.bin.tgz-t, a célgépen kitömöríted, kicseréled benne a hátteret, visszatömöríted (elég a sima .tar formátum, ekkor szedd ki a tar parancsból a z kapcsolót a mountapp.sh-ban) és visszaírod a /home-ba.
Ahhoz, hogy írjunk a home-ba, először írhatóvá kell tenni:
mount -o remount,rw /home
Hangsúlyozom, hogy mindez csak elméleti fejtegetés, még sosem próbáltam ki élesben, csak saját felelősségre :)
de szerintem működne, és ha nem használunk tömörítést, csak simán .tar-ban lenne a brutus, akár gyorsabban is indulhatna el a box!
Érdekes, hogy pontosan akkora a /home mérete, hogy éppen beleférjen ez a "dummy" 36 megás fájl, illetve a brutus tömörítve plusz a kicsomagoló script...
tmpfs dolog, ez a két módszer elvileg egy és ugyanaz, kérem a megerősítést tapasztalt Unix/Linuxosoktól :)
- van egy már meglévő pl. 16 megás állományod, legyen testfs.bin, ezt adod meg paraméternek és felcsatolsz egy 16 megás területet a memóriában, mondjuk a /test -be:
mount -nt tmpfs testfs.bin -o size=16384k /test
- a "semmiből" csatolsz fel egy 16 megás területet a memóriában, szintén a /test-be:
mount -nt tmpfs none -o size=16384k /test
elvileg mindegy, hogy mit adunk meg a tmpfs-nél 1. paraméternek, mert nem veszi figyelembe
mivel a mount szerint csak a / és a /data írható az Alligátorban (a többi (/var, /etc, /app) könyvtár csak a memóriában létezik, illetve a /home csak olvasható (induláskor egy script a /home-ból tömöríti ki a /app tartalmát :D), ezért a következő trükkök jöhetnek szóba:
1.
beleírsz egy plusz sort az ftp-s/oscam-os indító scriptedbe, hogy pl. a datáról másolja át a megfelelő helyre, pl.
cp -f /data/háttérképed1.jpg /app/still/default_1.jpg
cp -f /data/háttérképed2.jpg /app/still/default_2.jpg
ez így biztosan jó, mert az ftp, stb. után indul a brutus.
Valahol a kártyaolvasód menüpontja körül keresgélj és ott Show entitlements vagy valami hasonló lesz az. Hogy mi a neve, azt CA modulja és boxa válogatja.
pontosan! ami azért is lehet, mert időközben válaszolt az olvasó "nem talált"-tal, ekkor felkerül az adott állomány azonosító a rossz sid-ek listájára, és onnantól kezdve már nem fog arról az olvasóról próbálkozni.
maga a kliensed egyébként küldi az emm-eket, vagy le van tiltva? mert hiába engeded az olvasónál meg a felhasználónál, ha a kliensed nem küld semmit, ugyanott vagy.
vagy itt a kliens maga az oscam dvbapi interfésze, amely beleavatkozik a vett folyamba és ő maga kódolja ki a jelet?! (sajnos dvbapi-s box híján csak találgatok)
azon a transzponderen amit nézel, van emm folyam? a dvbapi-nak elvileg ki kellene írnia az erre utaló jeleket.
az is lehet, hogy a boxtype-ot a dvbapi-nál rendesen be kell állítanod. vagy próbálj ki egy másik, leginkább régebbi oscam-ot.
+1:
van egy olyan opció az oscamnál, ami mindig kényszeríti a dekódolást, decodeforever vagy decodealways valami hasonló a neve
Igen, lehet, az AV+ gombot kell megnyomni a fájlböngészőben. Előtte menj arra a partícióra, ahova a mentést akarod, hogy csinálja.
A visszatöltés meg elvileg úgy történik, hogy a fájlböngészőben megnyomod a kék gombot, amellyel csak a szoftverfrissítéshez való fájlok fognak látszani.
A Knowledge?
Az epg infó honnan jött? a Paprikásról vagy onnan, ahol a Knowledge is fent van?
Transedit szerint csak Conax van még rajta. De van magyar hangsáv! :)
Nyomd be a szerver honlapján alul a debug-nál az 1-est meg a 2-est és úgy nézd meg a naplót.
Ki kell írnia, hogy miért nem passzol a kérésekhez egyetlen olvasó sem.
A [dvbapi]-nál nem kell valami boxtype=dreambox vagy hasonló?
Ez az oscam magán a boxon fut, igaz?
Hasonló eset történt nem is olyan régen:
néztem egy csatornát, megnyomtam kézzel a felvételt, pár perc múlva jött a figyelmeztetés, hogy előjegyzett esemény folyamatban (mert korábban ugyanerre a csatornára beállítottam egy felvételt) hagytam továbbmenni, azután kifagyott. Egy pillanatra a fagyás előtt beugrott az az ablak, ahol beállíthatod, hogy mennyit vegyen fel.
A felvétel megy tovább, a kép/hang nem állt meg, a merevlemez LED-je is villog, viszont a box sem az előlapi gombokra, sem a távirányítóra nem reagál...
Telneten viszont be lehet lépni :D
az alábbi parancsok után
rendesen elindult a szoftver, majd ismét beugrott, hogy előjegyzett esemény folyamatban, nem nyúltam hozzá most sem és a felvétel elindult gond nélkül.
Ezek szerint a fagyásnál nem törlődött az esemény a listából, hiába indult el.
amitől működni fog:
- a kliensedben ne legyen tiltva az EMM küldés (ez kliens specifikus dolog, nézd meg a dokumentációját)
- az olvasódnál az AU disabled-nél nincs pipa, és az AU provider-t is üresen kell hagyni
- a felhasználódnál az AU nevezetű sor nem lehet üres vagy 0 értékű; ha 1, akkor minden olvasónak elküldi, különben név szerint meg kell nevezned őket, vesszővel elválasztva
- ugyancsak a felhasználódnál az EMM Reassembly opcióval is kísérletezz
- ha a fentieket már végigpróbáltad és még mindig nem megy, nézz utána a dvbapi-nak, valószínűleg ott is engedni kell ezt-azt
a timeout meg az időtúllépést jelenti, akkor van ilyen, ha X időn belül nincs valamelyik kérdésre válasz
a log mérete akkor számít, ha azon a partíción ahol tárolódik (de leginkább a memóriában, tmpfs típusú a partíció, ezt a mount paranccsal tudod megnézni) kevés a hely, a Configuration -> Global -> Log file / max size-t nézegesd.
Ha nem nőnek a számlálók a Readers oldalon, akkor valami nem stimmel.
Vagy ha tényleg jól van beállítva, egyszerűen csak ritkán küldik.
Egyébként az alsó sorban Switch Debug from... -nál érdemes benyomni az 1-est (részletes hibák) meg a 64-est (emm naplózás)
Mi a szerver, mi a kliens?
vagy ha egy gépen vannak, csak másik porton, és egymás feletti porton, akkor elég neki 1 kapcsolat és ott valahol a kék gombbal a kezdő meg a záró portot megadod, ahol a DES kulcsot is be lehet írni.
Szia!
milyen prioritással fut az oscam? (érdemes -10-re vagy -20-ra tenni a renice paranccsal,
vagy eleve úgy indítod, hogy a parancs elé odateszed a nice -n -20 -at.
mennyi az átlagos terhelés (load average)? ezt az uptime parancssal nézheted meg, vagy a top-pal.
akkor van magasabb válaszidő, amikor az oscamnak nincs elég ideje foglalkozni a kártyával, az usb-vel/soros porttal (nem tudom, hogy milyen olvasód van),
meg a hálózati kapcsolattal vagy egyszerűen csak a kártyád kap túl sok kérést
cardmhz/mhz=?
mi változott meg azóta, hogy alacsonyabb válaszidőid voltak?
esetleg fordíts egy új oscam-ot, már legalább a 8831-esnél tartanak...
szerintem nem teszed tönkre a törölgetésekkel, mivel a gombos induláskori frissítés a bootloaderben van benne (legalábbis remélem)
de felesleges törölgetni a /data-n kívül
/data/is_network.db: ebben vannak a hálózati beállítások + a cccam/newcamd sorok beállításai
/data/is_ch.db: ez a csatornalistád, a kódolásos dolgokkal együtt
szerintem elég, ha ezt a két fájlt törlöd plusz a többi felesleget, ha kell még hely
az oscamnál meg állítsd be, hogy a felhasználódnál uniq=0 vagy uniq=3 legyen, az utóbbi mindig csak a legutolsó csatlakozást fogja meghagyni
igen-igen, a statikus/dhcp dolog valószínűleg a beépített newcamd kliens hibája lehet. ha static címet használsz, akkkor a piros gombos menüből kézzel minden újraindításnál újra kell csatlakozni, cccamnál azt hiszem nincs ilyen, de ha egyszer valamit már newcamddal nyitott a box, nem tudom, hogyan lehet átrakni cccamra, ugyanis hiába kapcsolod ki a szerver kapcsolatoknál vagy törlöd ki az adatait, ugyanúgy használja, mintha még mindig ott lenne, pontosabban a megjegyzett sorszámú kapcsolattal próbálkozik.
nálam úgy van, hogy indulásnál az rc.user-es scriptből csatlakozik fel a wifi hálózatra, majd nyom egy dhclient-et is, hogy kapjon IP-címet, magán a felületen dhcp van beállítva és csupa nullás címet ír.
nagyon úgy néz ki, hogy a brutus hálózatkezelése nem egyezik a Linux sajátjával (ifconfig, stb.), akárcsak az óra kezelése sem.
az gáz, nálam is volt már hasonló
az oscam logban sorra mentek a found-ok, mégsem volt se kép, se hang. nem alligátoron semmi probléma nem volt.
megoldás:
először kitiltottam a box felhasználóját vagy (ha kábelen vagy, kihúzod a kábelt, vagy ha nem, akkor megszakítod a wlan kapcsolatot), aztán a boxon a zöld gomb ecm infónál megjelent a CW-knél csupa 0, majd visszaengedélyeztem a felhasználót, megjött a kép és a hang is, a CW-knél pedig mindkét sorban mentek a számok.
szerintem ez az, amit már mondtam, a szoftver néha eltéved a páros/páratlan CW-ket illetően
viszont te azt írtad, hogy gyári visszaállítást csináltál, olyankor a csatornalistát is törölni kell, ugyanis a csatornalistában tárolja el, hogy melyik csatornát milyen CAID-vel nyitotta legutóbb, mi az ECM adatfolyam pid azonosítója, stb.stb.
A -s kapcsoló akkor kell, ha string-ként adod meg a dátumot, különben így kell meghívni, ahogyan a man oldalon is olvashatjuk:
date [OPTION]... [+FORMAT]
date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
a maradandóhoz az kell, hogy újracsatold csak írhatóként a /-t, aztán
vagy telnetből szerkeszted: vi /root/rc.user
szerkesztés insert gomb, ha végeztél esc, aztán beírod, hogy :wq és enter.
vagy ftp-n keresztül feltöltöd a /root/rc.user módosított változatát
aztán chmod +x /root/rc.user
a legvégén meg visszacsatolod csak olvashatóra a /-t.
Nálam így működik hibátlanul.
A /var, a /etc és a /app azok csak a memóriában léteznek (ezt a mount parancs is elárulja, a fájlrendszerük tmpfs), ugyanis minden újraindításnál egy script kitömöríti a tartalmukat a megfelelő helyekre.
A /data-ban és a /-ben a fenti könyvtárakon kívül (így a /root-ban is) megmarad minden módosítás.
ps: a scriptedben a sleep 20 felesleges, ha mindenképpen várni akarsz valamennyit, elég a néhány másodperc, mondjuk 3-10 között.
Elküldve:
2013-09-02 10:20:01
