Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

    Nobody is reading this thread right now.

eleas

Newbie
Registriert
3. Juli 2011
Beiträge
8
Reaktionspunkte
0
Punkte
21
Hallo Forum,
war bisher immer nur ein stiller Mitleser, weil eigentlich die Suchfunktion ihrer Funktion immer gerecht wurde. Nun habe ich versucht auf einem Guruplug (armv5te) das SC-Plugin gegen den yavdr zu kompilieren, was an sich auch geklappt hat, nur kommen beim Testlauf der FFdecsa mehrere Fehlermeldungen dass der Test nicht bestanden ist.
Hat überhaupt schon jemand das Plugin für ein arm-System (guruplug, Sheevaplug, dockstar) kompiliert?
 
Re: AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Danke für die schnelle Antwort,

meine Vorgehensweise ist die Folgende:

-1-
Das Script "configure" aus "/usr/src/vdr-1.7.18/PLUGINS/src/sc/contrib/sasc-ng" gibt in die Datei "config.mak" folgendes aus:
-----------------------------
# Automatically generated by configure - do not modify
FFDECSA_OPTS = "FLAGS=-O3 -fexpensive-optimizations -funroll-loops -march=nativ$
CXX=g++
und Ausgabe Choosing "PARALLEL_MODE = PARALLEL_32_INT"
-----------------------------
-2-
Danach passe ich das "Makefile" in "/usr/src/vdr-1.7.18/PLUGINS/src/sc" folgendermaßen an:
-----------------------------
# FFdeCSA
CPUOPT ?= armv5te
PARALLEL ?= PARALLEL_32_INT
CSAFLAGS ?= -O2 -fexpensive-optimizations -funroll-loops
FFDECSADIR = FFdecsa
FFDECSA = $(FFDECSADIR)/FFdecsa.o
FFDECSATEST = $(FFDECSADIR)/FFdecsa_test.done
-----------------------------
-3-
Danach bekomme ich nach "make plugins" folgende Fehlermeldung:
-----------------------------
FAILED COMPARISON OF PACKET 29995
FAILED COMPARISON OF PACKET 29997
FAILED COMPARISON OF PACKET 29999
make[2]: *** [FFdecsa_test.done] Error 10
make[2]: Leaving directory `/usr/src/vdr-1.7.18/PLUGINS/src/sc/FFdecsa'
make[1]: *** [FFdecsa/FFdecsa.o] Error 2
make[1]: Leaving directory `/usr/src/vdr-1.7.18/PLUGINS/src/sc'
-----------------------------

Dein Script hat folgende Ausgabe gebracht:
-----------------------------
Unrecognised CPU.
Vendor:NotFound family:-1 model:-1
flags:
-----------------------------


Währe für einen Tip dankbar.

Mit freundlichen Grüßen
eleas
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Hallo Zusammen,

ich hab SC am Dockstar (2.6.35.7) mit diesen Werten erfolgreich kompilieren koennen:

Makefile:
...
# FFdeCSA
CPUOPT ?= armv5te
PARALLEL ?= PARALLEL_64_LONG
CSAFLAGS ?= -Wall -fPIC -g -O3 -fomit-frame-pointer -fexpensive-optimizations -funroll-loops
...

Kurze Info:
Mit dem Wert PARALLEL ?= PARALLEL_32_INT war bei mir die CPU-Last bei verschluesselten Sendern fast doppelt so hoch, wie mit 64_LONG
-O3 oder -O2 machen bei den CSAFLAGS hingegen keinen Unterschied.

Schoenen Tag noch.

robertogecco
 
Re: AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Danke für die Infos.

@robertogecco
Habe Deine Einstellung im Makefile ausprobiert mit dem Ergebniss:
------------------------------------------
FFdecsa 1.0: testing correctness and speed
FAILED!
FAILED!
FAILED!
FAILED!
CORRECT!
speed=13.131555 Mbit/s
speed=8920.893088 pkts/s
CORRECT!
FAILED!
CORRECT!
FAILED!
FAILED!
FAILED COMPARISON OF PACKET 1
FAILED COMPARISON OF PACKET 3
.
.
.
FAILED COMPARISON OF PACKET 29997
FAILED COMPARISON OF PACKET 29999
make[2]: *** [FFdecsa_test.done] Error 10
make[2]: Leaving directory `/usr/src/vdr-1.7.18/PLUGINS/src/sc/FFdecsa'
make[1]: *** [FFdecsa/FFdecsa.o] Error 2
make[1]: Leaving directory `/usr/src/vdr-1.7.18/PLUGINS/src/sc'
------------------------------------------

Das System auf dem ich kompiliere ist "Debian wheezy, 3.0.0-1-kirkwood".

Noch eine Idee?

mfg
eleas
 
AW: Re: AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

@eleas

Könntest du mal die Ausgabe von "cat /proc/cpuinfo" posten?
 
AW: Re: AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

@tecfreak

ae@debian:~$ cat /proc/cpuinfo
Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1191.11
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1
Hardware : Marvell GuruPlug Reference Board
Revision : 0000
Serial : 0000000000000000

mfg
eleas
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Hi eleas,

versuche mal
Code:
/bin/echo 2 > /proc/cpu/alignment
auf der Console, bevor Du mit dem Kompilieren beginnst.
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Guten Abend,
besten Dank an alle Beteiligten! Mit dem Tip vom "no sleep" ging es jetzt ohne Probleme!
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Hallo,
bei schlägt das Bauen des sc-plugins-deb unter der dockstar mit yavdr fehl. Hat jemand einen TIpp, wie ich das gelöste bekomme?
Danke

root@debian:/usr/local/src/vdr-plugin-sc-1.0.0+hg20111013# dpkg-buildpackage -rfakeroot -us -uc -b
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package vdr-plugin-sc
dpkg-buildpackage: source version 1.0.0+hg20111013-1~natty
dpkg-buildpackage: source changed by Best Friend <bPL3F1LMOotJ@mail.com>
dpkg-buildpackage: host architecture armel
dpkg-source --before-build vdr-plugin-sc-1.0.0+hg20111013
dpkg-checkbuilddeps: Unmet build dependencies: cdbs vdr-dev (>= 1.7.17) libssl-dev
dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
root@debian:/usr/local/src/vdr-plugin-sc-1.0.0+hg20111013#
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Hi,
ich hab nun den vdr mit sc am laufen ;)

Ich hab mir erstmal den vdr von yavdr.dockstar unstable per apt-get installiert.

Danach bin ich r Anleitung teilweise gefolgt und hab den VDR neu gebaut incl. dem sc-plugin + epgsearch und live ;)
Danach hab ich einfach die Libs und Binary ausgetauscht. Läuft wie geschmiert!

Schönes Wochenende!
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Hi,
ich habe leider noch Probleme mit dem sc-plugin.
Es entschlüsselt bisher noch keine Kanäle.

Folgende Fehler habe ich im Log gefunden:
Dec 28 08:07:53 debian user.err vdr: [17672] [general.error] failed open /var/lib/vdr/plugins/sc/smartcard.conf: No such file or directory
Dec 28 08:07:53 debian user.err vdr: [17672] [general.error] failed open /var/lib/vdr/plugins/sc/cardslot.conf: No such file or directory
Dec 28 08:07:53 debian user.err vdr: [17678] [general.error] socket: EOF on read
Dec 28 08:07:53 debian user.debug vdr: [17678] [cardclient.core] recv error. reconnecting...
Dec 28 08:07:53 debian user.err vdr: [17672] [general.error] too many CAIDs. You should ignore some CAIDs.

Das sc-log:
Dec 28 08:07:53.438 [general.info] loading keys from /var/lib/vdr/plugins/sc/SoftCam.Key
Dec 28 08:07:53.439 [core.load] loaded 3 keys from /var/lib/vdr/plugins/sc/SoftCam.Key
Dec 28 08:07:53.440 [core.load] ** registered systems:
Dec 28 08:07:53.440 [core.load] ** SC-Nagra (pri -5)
Dec 28 08:07:53.440 [core.load] ** SC-Irdeto (pri -5)
Dec 28 08:07:53.441 [core.load] ** SC-Cryptoworks (pri -5)
Dec 28 08:07:53.441 [core.load] ** SC-Conax (pri -5)
Dec 28 08:07:53.441 [core.load] ** Nagra2 (pri -10)
Dec 28 08:07:53.441 [core.load] ** Nagra (pri -10)
Dec 28 08:07:53.442 [core.load] ** Fake-NDS (pri -12)
Dec 28 08:07:53.442 [core.load] ** Irdeto2 (pri -8)
Dec 28 08:07:53.442 [core.load] ** Irdeto (pri -10)
Dec 28 08:07:53.442 [core.load] ** Cryptoworks (pri -10)
Dec 28 08:07:53.442 [core.load] ** ConstCW (pri -20)
Dec 28 08:07:53.443 [core.load] ** Conax (pri -10)
Dec 28 08:07:53.443 [core.load] ** Cardclient (pri -15)
Dec 28 08:07:53.444 [core.load] ** Viaccess (pri -10)
Dec 28 08:07:53.444 [core.load] ** Seca (pri -10)
Dec 28 08:07:53.444 [core.load] ** SC-VideoGuard2 (pri -5)
Dec 28 08:07:53.444 [core.load] ** SC-Viaccess (pri -5)
Dec 28 08:07:53.445 [core.load] ** SC-Seca (pri -5)
Dec 28 08:07:53.445 [general.info] Using software decryption on card 0/0
Dec 28 08:07:53.470 [cardclient.cccam2] server can't decode this ecm, (0 pending)
Dec 28 08:07:53.471 [general.error] socket: EOF on read
Dec 28 08:07:53.471 [cardclient.core] recv error. reconnecting...
Dec 28 08:07:53.471 [cardclient.cccam2] logout from server initiated
Dec 28 08:07:53.471 [cardclient.cccam2extra] reader thread stopped
Dec 28 08:07:53.471 [cardclient.cccam2extra] network shut down
Dec 28 08:07:53.471 [cardclient.cccam2extra] cmd 0c crypt mode now 0
Dec 28 08:07:53.472 [cardclient.cccam2extra] logout done
Dec 28 08:07:53.645 [general.error] too many CAIDs. You should ignore some CAIDs.
Dec 28 08:07:53.645 [core.ci] card 0/0, slot 0 (v= 1) caids: 0500 0100 0b01 1813 1803 1861 0d00 1817 09c4 1818 1819 1811 0b00 1833 0baa 0d03 1702 0b02 0d70 1863 0622 0624 0648 0d05 0d96 0604 0919 093b 0d95 09cd 0628 1810 0647 091f 09af 09c7 1830 1834 1837 1843 0d02 0d06 0d0f 1722 0614 0931 1801 183d 1860 4abf 0603 0608 0625 0662 0666 0960 0961 0963 09b2 0d01 0e00 1836 22e3 2600
Dec 28 08:07:53.646 [core.ci] 0/0: reset of slot 0 requested
Dec 28 08:07:54.348 [core.ci] 0/0.0: doReply changed, reset triggered
Dec 28 08:07:54.349 [core.ci] 0/0.0: now using CAIDs version 1
Dec 28 08:07:54.349 [core.ci] 0/0.0: status 'present'
Dec 28 08:07:54.449 [core.ci] 0/0.0: status 'reset'
Dec 28 08:07:55.051 [core.ci] 0/0.0: status 'ready'
Dec 28 08:07:55.251 [core.ci] 0/0.0 -> 00 01 82 01 01
Dec 28 08:07:55.252 [core.ci] 0/0.0 <- 00 01 83 01 01 80 02 01 80
Dec 28 08:07:55.252 [general.debug] internal: ci rb frame sync got=8 avail=8 - 06 00 00 01 80 02 01 80
Dec 28 08:07:55.553 [core.ci] 0/0.0 -> 00 01 81 01 01
Dec 28 08:07:55.553 [general.debug] internal: ci rb frame sync got=11 avail=11 - 09 00 a0 07 01 91 04 00 03 00 41
Dec 28 08:08:23.011 [core.pids] 0/0: now tuned to source 5300ff40(S19.2E) transponder 33a6f

Das kommt mir auch komisch vor.
Dec 28 08:17:59 debian user.err vdr: [18002] CAM 1: module ready
Dec 28 08:17:59 debian user.debug vdr: [18002] [core.ci] 0/0.0 -> 00 01 82 01 01
Dec 28 08:17:59 debian user.debug vdr: [18002] [core.ci] 0/0.0 <- 00 01 83 01 01 80 02 01 80
Dec 28 08:17:59 debian user.debug vdr: [18002] [general.debug] internal: ci rb frame sync got=8 avail=8 - 06 00 00 01 80 02 01 80
Dec 28 08:17:59 debian user.debug vdr: [18002] [core.ci] 0/0.0 -> 00 01 81 01 01
Dec 28 08:17:59 debian user.debug vdr: [18002] [general.debug] internal: ci rb frame sync got=11 avail=11 - 09 00 a0 07 01 91 04 00 03 00 41

Was läuft hier falsch?
DAnke DAnke
 
Zuletzt bearbeitet:
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

@Nirvana
HD ist überhaupt kein Problem, allerdings hängt der Guru bei mir an einer SATA Platte. Sollte aber theoretisch auch an usb keine Probleme bereiten.

@hampit
Fehlermeldung an sich sagt mir wenig, habe aber gestern sc zum vdr aus dem yavdr-repo gebaut, und es läuft. Wenn der Compiler sauber durchläuft müsste es laufen.
Viel Erfolg.
 
AW: VDR SC-Plugin auf einem Guruplug (arm) kompilieren.

Hallo.

@hampit
Heute, nach einem Neustart der Plug, habe ich den gleichen Fehler wie in deinem Log.
Jan 21 23:07:24.740 [general.debug] internal: ci rb frame sync got=8 avail=8 - 06 00 00 01 80 02 01 80
Jan 21 23:07:25.041 [core.ci] 0/0.0 -> 00 01 81 01 01
Jan 21 23:07:25.042 [general.debug] internal: ci rb frame sync got=11 avail=11 - 09 00 a0 07 01 91 04 00 03 00 41
Komisch ist es schon, dass es nach dem Bauen erst geht und sich erst nach einem Kaltstart verabschiedet.
 
Zurück
Oben