PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Linux ARM: Decoder Kommandozeilenversion für RaspBMC u.a.



orth0
25.02.2013, 17:48
Hallo zusammen,

ich nutze schon seit längerem die Kommandozeilenversion des Decoders für Linux. Um den Stromverbrauch zu senken, hab ich mir jetzt einen Raspberry Pi als HTPC und 24/7-Download-Rechner eingerichtet und würde darüber gern auch meine Sendungen dekodieren.
Ich habe den ARMV5 Decoder probiert, leider funktioniert er nicht.

Gibts überhaupt einen Decoder für diese PLattform oder wird in absehbarer Zeit einer erscheinen?

Administrator
25.02.2013, 17:53
nein, neue decoder kommen keine mehr..dafür haben wir ja die uncodierten dateien jetzt auch ueber mirror (auch ftp) ermöglicht..

dmjr
25.02.2013, 18:24
Welcher Mirror unterstützt FTP-Push von uncodierten Dateien?

huchmampf
26.02.2013, 17:17
Seh ich das richtig, dass es nie einen Decoder/EasyDecoder für ARMv6 geben wird?
Ist der Aufwand so groß, es dafür zu kompilieren?
Gerade der RaspberryPi benutzt einen ARMv6 und wäre ideal als HomeServer geeignet.

hillibilly
27.02.2013, 10:54
Ich wollte mir eigentlich auch einen Raspberry Pi für die anfallenden OTR Aufgaben kaufen und einrichten, aber anscheinend sind die notwendigen Programme nicht für ARMv6 kompiliert (auch der HLT Client). Schade eigentlich.
Wenn jemand einen Raspberry Pi entsprechend eingerichtet und automatisiert hat, dann wäre ich sehr an dieser Lösung interessiert.
Zur Zeit benutze ich auf meinem DesktopPC unter Ubuntu QBittorrent um den RSS Feed meiner Aufnahmen automatisiert herunterzuladen. Anschließend das multicut_light Script von Bloodrayne zum dekodieren und schneiden. Zum Schluss das Script EPG-Rename von n3tc0mm welches ich leicht verändern musste um es bei mir lauffähig zu bekommen.
Das ganze funktioniert ja leider so nicht auf einem Raspberry Pi.

Gruss
hillibilly

0daredevil0
03.03.2013, 21:55
Gut, die Person, die den Dekoder erstellt hat ist nicht mehr da.

Aber wenn von dem Dekoder der Sourcecode existiert und dieser ausrechend dokumentiert ist, müsste es doch möglich sein eine neue Version zu erstellen/den Dekoder weiter zu entwickeln. Da ist nie doch schon ziemlich hart.

Der trend zu den unkodierten Dateien kann ich nicht verstehen, es ist einfach nicht akzeptabel. Das ganze Mirror System ist darauf aufgebaut. Irgendwelche Mirror die unkodierte Dateien anbieten würde ich nicht vertrauen.

Crout
04.03.2013, 07:16
Bleiben noch die Argumente dass man unkodierte Dateien nicht mit Torrents prüfen kann (dann kann man auch die Hash's in der Übersicht weglassen, es lebe der Rückschritt), und dass die Community die unkodierten Dateien doch eigentlich garnicht möchte? Gegen eine Ergänzung hat ja niemand was, aber es sieht schwer danach aus als wären die unkodierten Dateien das Ziel der allgemeinen Politik von OTR.

Crout
04.03.2013, 12:03
Das finde ich Top, Daumen hoch!
In diesem Fall könnte man aber auch dem Thread-Ersteller unter die Arme greifen und den Sourcecode für den Decoder veröffentlichen (die Rechtssicherheit lässt sich mit einmaligen Schlüsseln für die Dateien ja auch weiterhin wahren), in der Community gibt es ja genug Entwickler die in der Lage sind das Programm dann auch für ARM zu kompilieren oder zur Not proprietären Code neu zu schreiben.
Das wiederum könnte dann zu einer Community-getriebenen Version eines OTR-Receiver mit einem Raspberry-Pi inklusive Fileserver und automatischem Download führen - und was wäre cooler?

Aha
07.03.2013, 08:27
bei otr wird es ohnehin die OTRKEY-dateien weiterhin geben. Und auch bei den Mirrorn haben sich einige dazu entschieden, weiterhin nur otrkey-Datein anbieten zu wollen. Also ich seh kein Problem darin zweigleisig zu fahren. Und der Aufwand ständig für neue Platformen decoder zu schreiben und dann den support zu machen ist einfach zu hoch. Entwickler machen selten auch noch support nach 2 Jahren, spätestens dann liegt die Arbeit wieder bei uns. Und dazu ist die Anzahl der Spezial-Platform user einfach zu gering. Die verweisen wir daher auf uncodierte Dateien jetzt.

Bei allem Respekt, aber für die aktuellen Decoder gibt es doch auch keinen Support mehr.

Administrator
07.03.2013, 09:47
nein, das stimmt nicht. Der Standarddecoder wird ständig verbessert und gepflegt (auch support hier). Beim Easy-Decoder sieht es tatsächlich weniger gut aus (keine Weiterentwicklung derzeit mehr).

Artemis1121
07.03.2013, 10:21
da in dem Thread
http://www.otrforum.com/showthread.php?69576-Dekoder-f%C3%BCr-Marvell-Kirkwood-mv6282
hierher verwiesen wird:

Die Synology Diskstation 112+ hat den gleichen Prozessor wie ein Sheevaplug, nämlich einen Feroceon 88FR131, wie man unter anderem hier (http://www.synology-wiki.de/index.php/Welchen_Prozessortyp_besitzt_mein_System%3F) nachlesen kann.
Auf meinem Sheevaplug läuft schon seit 3Jahren und 3Tagen - Mist Jubiläum verpasst - der Testdekoder aus dem Thread:
http://www.otrforum.com/showthread.php?44730-otrdecoder-f%FCr-NSLU2-debian-%28little-endian%29&p=294985&viewfull=1#post294985

und hier der direkte Link zum Dekoder:
http://www.onlinetvrecorder.com/downloads/otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148.tar.bz2

hillibilly
08.03.2013, 16:11
Asche über mein Haupt. Das mit dem alten ARM Decoder wusste ich nicht.
Kann denn bitte jemand mit einem RaspberryPi mal diesen Decoder ausprobieren?

@Admin: Ich verstehe ja dass man priorisieren muss. Es hört sich doch sehr nach dem Henne/Ei Problem an. Ich werde mir für die anfallenden OTR Tätigkeiten keinen RaspberryPi kaufen, wenn ich vorher schon weiß dass es nicht funktioniert wie ich es mir vorstelle. Ich glaube, dass es anderen Usern ähnlich geht.
Aber vielen Dank für das Angebot der Sourcen. Ich selber verfüge leider nicht über die entsprechenden Fähigkeiten (leider).

Gruss
hillibilly

hillibilly
09.04.2013, 14:52
Hallo Hybrid666,

ich kann Dir (und allen anderen RaspberryPi Nutzern) nur die Daumen drücken, dass Dein Angebot auch ohne Vertrag angenommen wird. Es gibt ja auch zig andere Projekte rund um OTR die ohne vertraglich verpflichtenden Support aber mit freiwilligem Forumsupport funktionieren. Ich bin jedenfalls von der Idee alles auf dem RaspberryPi laufen zu lassen begeistert. Was läuft denn schon bei Dir für die OTR Nutzung?

Gruss
hillibilly

Hybrid666
11.04.2013, 10:41
Laufen tut alles außer eben der dekodieren, wozu ich alles auf meinen desktoprechner ziehen muss. Aber mein Plan ist es, alles zu automatisieren. Sprich die Dateien kommen per FTP Push an, da hab ich einen modifizierten FTP Server drauf, der beim beenden einer übertragung den decoderjob startet, dannach nach einer cutlist sucht und das ggf. schneidet, dannach landen die fertigen dateien dann in einem Verzeichniss, das von einem DLNA Server überwacht wird, damit ich das direkt auf meinem TV ansehen kann...

Hybrid666
23.04.2013, 08:54
ich denke nicht, dass wir hier noch rückmeldung vom admin kriegen :( schade.

hillibilly
23.04.2013, 10:07
ich denke nicht, dass wir hier noch rückmeldung vom admin kriegen :( schade.

Hattest Du eine Mail an Webmaster@... geschrieben? Vielleicht liest Werner nicht mehr mit.

Gruss
hillibilly

Administrator
23.04.2013, 12:34
doch, doch, sorry, war busy.

also wir können gerne so machen: Ihr sendet compiler, wir jagen den code durch und fertig.
alles andere ist zu umständlich/riskant , angesichts der ja nun vorhandenen möglichkeiten bzgl. download uncodierter dateien via mirror und otr. (sogar auch ftp/stream/download)

Gruß Werner

Hybrid666
29.04.2013, 07:23
Auf welcher Platform möchtest du denn die compiler? Linux, Windows, 32bit, 64bit? Welche abhängigkeiten müssen dabei sein?

Falls es dir sorum lieber ist: Ich kann dir gerne einen Zugang zu meinem Raspi Server geben, da kannst du dir im Home einen verschlüsselten container anlegen, den code reinlegen, compilen und die binary rausziehen.

Und keine Sorge: Ich hätte nichts schlimmes mit dem Code gemacht ;). Ich hab keinerlei interesse dran das Angebot von OTR in iregendeiner Form zu gefährden, da ich das angebot klasse finde!

Gruß

Administrator
29.04.2013, 08:14
Am liebsten Windows 64bit

Hybrid666
29.04.2013, 09:09
Das würde dann allerdings in einer Cygwin umgebung laufen, wäre also arbeit für dich, alles in die Umgebungsvariablen reinzupacken. Wäre eine fertige Linux VM mit dem Cross Compiler auch OK für dich?

Administrator
29.04.2013, 09:32
ich denke schon -> bitte schreib per email weiter.. ich gebs dann an die Entwickler

antion
29.05.2013, 14:11
Gibt es inzwischen schon einen Dekoder für ARMv6? Würde auch gerne meinen Raspberry hierfür benutzen!

Administrator
29.05.2013, 15:40
jemand müsste uns testweise einen raspberry mit compiler senden,, dann geht das ratzfatz

antion
29.05.2013, 16:00
Also testen kann ich immer gerne... aber meinen Raspberry geb' ich nicht mehr her ;-)
Gibt's denn keine Möglichkeit, das per Cross-Compiling zu kompilieren?

BerndDasBrot
04.06.2013, 08:07
Ich könnte meinen Raspberry für einen Remotezugriff zu Verfügung stellen... wäre das ausreichend?
Vorausgesetzt Hybrid666 würde dort den Compiler installieren oder mir sagen wie das geht...

0daredevil0
14.07.2013, 12:50
Gibt es noch irgendwelche Fortschritte?

Benötige einen Decoder für mein RaspberryPI :)

BerndDasBrot
15.08.2013, 19:46
Ich habe von keinem was gehört...

jumper89
01.09.2013, 16:46
Wäre auch an einer automatisierten Lösung mit einem Raspberry Pi interessiert.
FTP-Push -> automatisches Dekodieren -> (evtl. schneiden) -> ins XBMC (Raspbmc) importieren und am Fernseher anschauen. Das wäre doch ein Traum :)

Klaus_Dieter
09.09.2013, 19:00
sicher macht man das nicht im Vorbeigehen, den otrdecoder für arm zu übersetzen und es gilt viele Fragen zu berücksichtigen:
* wie sicher ist der Kodierungsmechanismus noch, wenn der Code herausgegeben wird
* Wer führt den Support durch
* Wieviele Plattformen möchte man überhaupt unterstützen
* Welche Zusatzfunktionen werden gebraucht.
All das wurde bereits zigfach ergebnislos in diesem Forum diskutiert. Die Threads lassen sich mit der Suche recht einfach finden.
Fakt ist: Bis sich mal jemand auf den Hosenboden setzt und einen Decoder für ARM übersetzt, gibt es keine native Lösung.
Auf der Suche nach einer Lösung für das Problem habe ich eine Zwischenlösung über qemu gefunden. Das funktioniert auf arms wie der Dreamplug und auch dem Raspi und ist auch nicht sonderlich schnell, aber es geht immerhin, sodass ich auf meiner Dreamplug nun otrkeys entschlüsseln kann. Siehe dazu der separate Thread.

Klaus_Dieter
09.09.2013, 21:03
Hi Hybrid666

womit genau schneidest Du die avis auf dem Raspi?
Auf meiner ARM-Kiste bekomme ich avidemux zwar kompiliert aber das binary enthält Code, der auf arm nicht ausführbar ist - wahrscheinlich irgendwas in den Codecs.
Über konkrete Hinweise dazu wäre ich sehr dankbar.

Artemis1121
27.09.2013, 15:05
da ich leider deinen Anhang nicht sehn kann, spekuliere ich mal:
ich hatte damals als der erste ARM Decoder raus kam auf meinen Sheevaplug mitgetestet. dort war die Verifizierung auch immer fehlerhaft, obwohl ich via Torrent lade und die Dateien somit schon gecheckt waren. Ohne Verifizierung ließen diese sich fehlerfrei dekodieren. könntest du das auch mal testen?

jumper89
27.09.2013, 15:41
Habe ich auch probiert, also mit -q in der Konsole aufzurufen. Kam der gleiche Fehler.
Hier nochmal das Bild nicht als Anhang:
https://dl.dropboxusercontent.com/u/167809/F%C3%BCr%20Foren/otr_arm_test.jpg

Artemis1121
27.09.2013, 17:44
Kann leider nicht mittesten, da der decoder auf meinem armv5 nicht läuft.


xxxxxxxx@plug:~/otrtest# ./otrdecoder_arm --help
-bash: ./otrdecoder_arm: No such file or directory
xxxxxxxx@plug:~/otrtest# ./otrdecoder-static_arm --help
Illegal instruction


kannst du mal schaun, was ldd zu den beiden Dateien sagt? Das listet auf, welche libs benötigt werden, aber da scheint was nicht zu stimmen, angeblich beide nicht dynamisch gelinkt..

xxxxxxxx@plug:/media/maindata/torrent/decoded# ldd ~/otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148/otrdecoder
not a dynamic executable
xxxxxxxx@plug:/media/maindata/torrent/decoded# ldd ~/otrtest/otrdecoder_arm
not a dynamic executable
xxxxxxxx@plug:/media/maindata/torrent/decoded# ldd ~/otrtest/otrdecoder-static_arm
not a dynamic executable


Und das mit der nicht funktionierenden Verifizierung muss ich zurücknehmen, obwohl ich mir sicher war, das die nicht funktionierte. Geht problemlos :)

xxxxxxxx@plug:/media/maindata/torrent/decoded# ~/otrdecoder-bin-arm-unknown-linux-gnu-static-0.4.1148/otrdecoder -e xxxxxxxxx@gmx.de -p xxxxxxxxxx -i xxxxxxxhr3_45_TVOON_DE.mpg.avi.otrkey

Could not verify login: Error: Could not connect to server to verify account data.
Verifying input ...
Successfully verified input.
Check authorization ...
Authorized.
Decoding ...
Successfully decoded.
Verifying output ...
Successfully verified output.
Sorry für OffTopic!

jumper89
27.09.2013, 18:46
Hier der Output von ldd, kannst du damit was anfangen?



pi@raspberrypi ~/otrtest $ ldd otrdecoder_arm
/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6fa5000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6ecd000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e5c000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6e34000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d05000)
/lib/ld-linux-armhf.so.3 (0xb6fb2000)

pi@raspberrypi ~/otrtest $ ldd otrdecoder-static_arm
not a dynamic executable


Bei mir werden zumindest bei dem dynamisch gelinkten die Libs aufgelistet und bei dem statischen nicht, so muss es ja auch sein. Ich vermute jetzt einfach mal das die kompilierte Version des Decoders auf Grundlage einer älteren Version für die jetzigen otrkey Dateien nicht mehr geht und wir doch eine kompillierte Version auf Grundlage einer etwas neueren Version bräuchten...??!


Nachtrag:
Noch etwas genauere Infos aus ldd, vllt. hilfreich, ich kann mit den verschiedenen Libs nicht so viel anfangen:


pi@raspberrypi ~/otrtest $ ldd -v otrdecoder_arm
/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6fd4000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6efc000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e8b000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6e63000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d34000)
/lib/ld-linux-armhf.so.3 (0xb6fe1000)

Version information:
./otrdecoder_arm:
libgcc_s.so.1 (GCC_3.5) => /lib/arm-linux-gnueabihf/libgcc_s.so.1
libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
libstdc++.so.6 (CXXABI_ARM_1.3.3) => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
libstdc++.so.6 (CXXABI_1.3) => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so:
libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6:
ld-linux-armhf.so.3 (GLIBC_2.4) => /lib/ld-linux-armhf.so.3
libgcc_s.so.1 (GCC_3.3) => /lib/arm-linux-gnueabihf/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.5) => /lib/arm-linux-gnueabihf/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.0) => /lib/arm-linux-gnueabihf/libgcc_s.so.1
libm.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libm.so.6
libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
/lib/arm-linux-gnueabihf/libm.so.6:
ld-linux-armhf.so.3 (GLIBC_PRIVATE) => /lib/ld-linux-armhf.so.3
libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
/lib/arm-linux-gnueabihf/libgcc_s.so.1:
libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
/lib/arm-linux-gnueabihf/libc.so.6:
ld-linux-armhf.so.3 (GLIBC_2.4) => /lib/ld-linux-armhf.so.3
ld-linux-armhf.so.3 (GLIBC_PRIVATE) => /lib/ld-linux-armhf.so.3

pi@raspberrypi ~/otrtest $ ldd -u otrdecoder_arm
Unused direct dependencies:
/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
/lib/arm-linux-gnueabihf/libm.so.6
/lib/arm-linux-gnueabihf/libgcc_s.so.1

Artemis1121
30.09.2013, 06:59
ich war nur verwundert, das da überhaupt nix rauskam bei ldd.. bei dir passts ja!
da kann wohl nur otr.th weiterhelfen.