Biztos, hogy network módba állítottad a dvbapi plugint??
/tmp/camd.socket - a lokális oscamot keresi.
Más: ma fordítottam egy fórumtársnak egy szűz ubuntun egy szűz vdr-t sc-vel és streamdev pluginnal, semmi más nem volt benne. Szépen indul, fut és megáll, semmi hiba.
Ez van a system.logban:
DVBAPI-Error: Cannot connect to /tmp/camd.socket, Do you have OSCam running?
Pedig fut.
Mi csinálja ezt a camd.socket -et?
Az sc-vel csak az a bajom, hogy vele az új vdr leállítása nem sima, sokszor erőszakkal kell kilőni, mivel lebegőpontos hibát, vagy malloc() hibát jelez és belefagy.
De nem mindig.
Elolvastam a dvbapi readme-jét, gondolom te is. Azért leírom, hogy mit értettem meg belőle:
az oscam.conf -ba, a [dvbapi] résznél kell egy ilyen sor:
listen_port = 2000 (tetszőleges port)
Oscam verzió: min. rev9580
A dvbapi pluginban engedélyezed a network módot, és megadod az ip-t, meg portot:
dvbapi.OSCamNetwork = 1
dvbapi.OSCamHost = 192.168.0.1 (az amiko ip-je)
dvbapi.OSCamPort = 2000 (megegyezik a fenti porttal)
Én csak lokálisan futó oscam-ra csatlakoztam. De olvastam valamit a dvbapi historyjában (?), hogy talán lehet távoli oscamhoz is csatlakozni,
De mi a baj az sc-vel, azt írtad, végül lefordult?
Hogy a nyavalyába kell ezt a vdr-dvbapi cuccot konfigurálni, hogy külső oscam szerverre csatlakozzon vele a vdr és működjön is?
Ez lenne az igazi.
A külső oscam szerveren már van egy dvbapi felhasználó, maga a box user és nem pc box típussal.
A vdr-dvbapi meg pc boxtype dvbapi szekcióval csatlakozna a leírás szerint.
Kínomban...
Csináltam a pécémre egy oscam -ot az svn-ből. El is indítottam, na nem damon módban. Csináltam neki oscam.server, oscam.conf, oscam.user fájlokat kitöltve.
Egy readert az oscam.server fájlba, ami a boxomról olvas cccam protokollal.
Egy vdr usert is csináltam ami a helyi oscamra csatlakozik.
Még a webif -je is megy, nem csak az amiko oscam webifje.
A vdr setup.confba beleraktam a dvbapi leírás alapján a 3 db konfigurációs sort, majd elindítottam sc plugin helyett a dvbapi pluginnal.
A webifen él a boxom readere és rajta van a vdr user is, de nem csinál semmit.
Semmi emm -et nem küld senkinek.
UHU ubk-2.2 alá is elkészítettem, itt is van ilyen hiba leálláskor:
<!--kod start-->*** glibc detected *** /usr/bin/vdr: malloc(): memory corruption: 0x095c5d60 ***<!--kod end-->
De itt legalább leáll a VDR, még ha a terminál, amiből indítottam volt, a billentyűzetet már nem is érzékeli.
De legalább becsukható.
És menübül indítva a vdr-t leáll és a terminálja is becsukódik.
VDR portálon több panasz is van, nem fordulnak le pluginok, úgyhogy biztos el kell teljen néhány hét, amíg mindenhez meglesz a patch. Egy dolog biztosnak látszik: a vdr core már nem fog érdemben változni a 2.2 előtt.
Lehet, hogy magamnak megcsinálom, ahogy én kedvelem, de ilyen hiányosságokkal nem fogom publikálni az UHU csomagokat.
Stabil leállítás az követelmény minden megjelenítővel és bármely plugin használatával.
A skinnopacity is követelmény nálam, nem akarom a felhasználókat választási kényszer elé állítani. A xineliboutput ütközik a skinnopacity-vel, egyszerre nem használhatók.
A setup plugin mondjuk kiváltható a menuorg pluginnal.
Nem kell sietni a frissítéssel, meg kell várni, míg a hibák kibuknak és kijavítják azt, amit lehet.
Egyre több gond van a VDR-2.1.9 -el.
1. A xineliboutputból csak a legújabb svn változat jó neki, de az nem add true-color módot a --hud opcióval indítva, tehát a skinnopacity -val nem használható.
2. Az sc csak a régebbi forrásból építhető fel.
3. Az sc plugin csak a xineliboutput kombinációval eredményezhet biztonságos VDR leállítást.
4. setup plugin nem alkalmazható többé a VDR -hez, nincs hozzá extensions folt.
Egyelőre ennyi, én maradok még a 2.0.7 -es VDR-nél.
Még nem adtam fel teljesen, megpróbálom a gittel kifoltozni a softhddevice plugint, meg változtatok az sc FFDECSA opción, hátha nem jó neki az a PARALLEL_32_INT, amivel csináltam.
Gondolom az is okozhat memóriazavart.
Én is használom a vdr-sxfe-t a mai napig, és igen jók a tapasztalatok. A médialejátszó része miatt maradok is vele. A két másik kliensen pedig maradnak a raspberry pi-k, azok is nagyon jók és stabilak.
Ezt a softhddevice -t ki fogom hajítani még a végén!
Most tudtam kipróbálni a friss sc plugin csomagomat élesben és sofhddevice alatt kiakad a VDR a leálláskor:
febr 12 17:33:10.771 [cardclient.cccam2] logout from server initiated
*** Error in `/usr/bin/vdr': malloc(): memory corruption: 0x091bb6b0 ***
A xineliboutputtal nincs ilyen gond, azzal szépen dönget és le is állítható szótlanul a VDR.
Az, ami lefordult a 2.0.7 VDR -el, 2.1.9 -el nem fordul le, amint beidéztem a hibát.
A régebbinek mondott (0.9.3.20120815) az, ami lefordult, csak kicsit megfoltoztam a makefilét az újabb VDR verziókhoz.
Meg még pár dolgot, hogy legyen neki libsc-dvbsddevice,so -ja és libsc-dvbhddevice.so -ja is.
Persze ehhez a vdr-dev csomagot is ki kellett bővítenem a dvbhddevice és dvbsddevice fejlécekkel és forrásaikkal
Stabilan ment nekem az ffdecsawrapper, de nem nyerte meg a tetszésemet, komplikáltabb az elindítása és kissé a setétben dolgozik.
A sima sc -vel meg el sem kell indítani semmilyen okosságot, ha csak kliensként megy a vdr, akkor simán rá tudom csatlakozni a vdr-t cccam protokollal az alienemre, amiben oscam dübörög. egyébként meg el kellne indítani a pécén előbb az ffdecsawrappert, ami a vdr -től függetlenül megy.
Viszont az ffdecsawrapperhez semmilyen plugin sem kell a vdr-nek.
Ha nem tudom megoldani az sc -t az újabb védéerhez, akkor a dvbapi -ra szorulok.
Hát neki aztán tényleg hiába. Nagyon rá van gyújtva, hogy hétvégén meglegyen az új stabil verzió a 15. szülinapra. Nem fog már változtatni a kódon, max. kozmetikázni.
A fordítási hibához nem tudok hozzaszólni :(
A vdr és ffdecsawrapper kombó stabil? Mi a hátránya az sc-hez képest?
sed -i device.c -e s:MAXDVBDEVICES:MAXDEVICES:
sed -i sc.c -e s:MAXDVBDEVICES:MAXDEVICES:
export PARALLEL=PARALLEL_64_MMX
Majd hajrá!
lefordít 5 c fájlt, majd jő a hiba.
<!--kod start-->device.c:1297:0: warning: "DEV_DVB_ADAPTER" redefined [enabled by default]
#define DEV_DVB_ADAPTER "/dev/dvb/adapter"
^
In file included from device.c:30:0:
/usr/include/vdr/dvbdevice.h:74:0: note: this is the location of the previous definition
#define DEV_DVB_ADAPTER "adapter"
^
In file included from device.c:29:0:
/usr/include/vdr/ci.h:184:16: error: 'virtual bool cCamSlot::Reset()' was hidden [-Werror=overloaded-virtual]
virtual bool Reset(void);
^
device.c:546:8: error: by 'bool cScCamSlot::Reset(bool)' [-Werror=overloaded-virtual]
bool Reset(bool log=true);
^
device.c: In member function 'virtual bool cScDevice::Ready()':
device.c:1562:34: error: 'class cScCiAdapter' has no member named 'Ready'
return (ciadapter ? ciadapter->Ready():true) &&
^
device.c:1563:38: error: 'class cCiAdapter' has no member named 'Ready'
(hwciadapter ? hwciadapter->Ready():true);
^
device.c:1564:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
cc1plus: some warnings being treated as errors
make: *** [device.o] Error 1
HIBA a(z) compile fazisban.<!--kod end-->
Az előző 2.0.7 -es VDR fejlécei jók voltak neki, szépen létrejött a plugin.
Szerintem Kls -nek hiába is írnék a VDR portálon, pedig ő a ludas a VDR kódjának változtatásban.
Köszi. Ez egy jó ötlet, majd beledrótozom a vdr csomagkészletembe.
Én a softhddevice-t használom általában szinte mindig.
A leállíthatatlanság okának is a közelében járok, az sc pluginomat kihagyva szépen leáll a VDR. Csak kódolt adót nem lehet így venni.
Most a közben megszűnt git://github.com/bas-t/sasc.git tárolóból készült sc van UHU -n a VDR 2.0.7 -hez. Erről készítettem egyébként fork -ot valaha én is.
Az új VDR-hez ezt nem tudtam lefordítani eddig.
Ez valaha Arch-linuxon az 1.01 -es verzióval szerepelt és 2013.10.30 -i dátummal jött le a forrása. Ahhoz még új Makefile foltozást is csináltam, de ez az új VDR keresztbetett valamivel neki.
Most az Arch-AUR -on lévő PKGBUILD alapján tudtam lefordítani a http://vdr.websitec.de/download/vdr-sc/vdr-sc-0.9.3.20120815.tar.gz forrást.
Ez a dátum szerint régebbi, de ezek szerint nem épp a legstabilabb.
Erre nem tudok válaszolni, mert soha nem használtam élesben a softhddevice-t (elsősorban a bonyolult függőségei miatt). De tanítsd be konzolon -Pskincurses -al, aztán hajrá!
Lehet használni. Az ffdecsawrapper daemon újabb dvb virtuális eszközöket hoz létre a /dev alatt, azt kell használni annak a videólejátszónak, amivel az adást nézni akarod, Ez lehet akár a VDR is, hisz ott is be tudod állati a használni kívánt eszközt.
Már vagy egy éve, hogy próbáltuk Bandikával.
Ő csinálta belőle a csomagot is UHU alá.
Más gondom van, most vettem észre.
A táv/billentyű betanítás a softhddevice pluginnal nálam nem működik, csak feketeség van, majd megjelenik a TV adás kid idő múlva.
A xineliboutputtal megy, de ott is csak a --hud opcióval.
Rendjén van az, hogy sofhddevice megjelenítővel nem megy a betanítás?
Elküldve: 2015-02-14 20:12:31, 
