Reel NetClient - IP Streaming Client & mobiler Mediaplayer
- magicdragon67
- Geschlossen
-
-
Interessant finde ich das Teil auch.
Zur Ausgabe wird dort auch nicht der Micronas Chip sondern ein anderer bentutzt.Ob man das mit einem normalen VDR ohne Netceiver benutzen würde mich auch interessieren, das werden wir aber erst sehen wenn es auf den Markt kommt.
Leider finde ich es als reines Bastelobjekt mit 300€ für mich zu teuer, aber als Streamingclient ist der Preis ansich angemessen.
-
Jo,
ich würde es auch investieren, wenn ich wüsste, wie es mit was zusammen tut.
Grüße
-
der netclient läuft auch nur mit dem netceiver man braucht keine avg
ein neuer (gleiche technik nur halt kleiner, anderes platinenlayout)
kompakter netceiver + passendes gehäuse und netzteil wären in arbeitdas teil dürfte auch mit nem normalen vdr als server laufen bei der avg ist ja auch das streamdev-client plugin dabei
-
Na, es ist ja bald Ostern !
Hört sich gut an bin gespannt!!!!!!!!
-
"Ob man das mit einem normalen VDR ohne Netceiver benutzen würde"
Sollte man schon können, wenn jemand das Ausgabe-PI passend portiert. Wir nehmen eben wieder den reelvdr, der macht halt schon alles, was wir so brauchen (Villa Riba vs. Villa Bacho ).
-
ich war heute auf der ANGA in koeln, wo reel auch den netclient und netceiver gezeigt hat. war echt beeindruckend. ich denke dass ich die loesung bei meiner naechsten multiroom installation einsetzen werde. kosten halten sich in grenzen.
-
Wird für den Client das Streamdev Server Plugin verwendet?
-
hab das teil zwar nicht
dürften aber denke ich beide lösungen möglich sein
das er vom netceiver direkt daten bekommt oder per streamdev
-
und hat jemmand den Reel NetClient schon im Einsatz?
-
Hi!
Ja, ich habe so ein Teil im Einsatz (mit Netceiver).
Ich besitze auch keine AVG. Eigentlich brauche ich so eine AVG auch nicht.Ein eigener VDR lässt sich bestimmt einbauen. Im SVN sind prinzipiell alle Dinge vorhanden, um so etwas zu bewerkstelligen.
Das Grundsystem des Netclients ist ein Debian Lenny(?) für ARM(armel).
Die Anbindung der AV-Hardware erfolgt über ein Plugin namens rbmini. Dieses erstellt im VDR ein Ausgabe-Device. Dieses müsste an den aktuellen VDR angepasst werden.Was nicht offen ist, sind die Quellen der Kernel-Module zur Kommunikation mit dem Conexant/NXP Prozessor. Aber mich persönlich stört das nicht.
Entwickeln lässt sich mit dem Teil auch komfortabel, da das ganze System von einem internen USB-Stick läuft. Dieser wird einfach ausgetaucht. Beim Bootvorgang wird mittels pivotroot auf das neue rootfs des Sticks gewechselt.
Ansonsten kann man auch direkt hinten an die RS232 des Netclients und direkt den UBoot bedienen.
Momentan beschäftige ich mich damit, erstmal das Original-Reel-Image für das Teil nachbauen zu können. Die DEB-Pakete aus dem SVN bekomme ich in der passenden chroot-Umgebung mit dem Armel-Cross-Compiler auch übersetzt. Leider bekomme ich nirgendwo eine Info, wie das Basis-Image erstellt wird.
-
Arbeitet Reel auf Basis eines VDR 1.7.0, also HD als PES (.VDR-Files) aufgezeichnet? Oder sind Aufzeichnungen im .TS-Format?
Ich überlege, ob ich mir einen AsRock ION als Client anschaffen soll oder so einen NetClient. Der müsste allerdings mit einem aktuellen VDR 1.7.10 zusammenarbeiten, ich kann nur mit TS-Recordings leben...
-
Zitat
Original von batDan
Arbeitet Reel auf Basis eines VDR 1.7.0, also HD als PES (.VDR-Files) aufgezeichnet? Oder sind Aufzeichnungen im .TS-Format?Ich überlege, ob ich mir einen AsRock ION als Client anschaffen soll oder so einen NetClient. Der müsste allerdings mit einem aktuellen VDR 1.7.10 zusammenarbeiten, ich kann nur mit TS-Recordings leben...
Reel Arbeitet auf gar keiner Basis.
Sie haben sich den vdr-1.4 geschnappt und für ihre Zwecke angepasst.
HD Aufnahmen werden im TS format aufgenommen, haben aber die endung *.vdr und das index File wird vermutlich auch nicht kompatibel sein.
SD Aufnahmen werden im VDR 1.4 Format aufgenommen PES.mfg Thomas
-
> Reel Arbeitet auf gar keiner Basis.
Naja, Anfang 2007 war HDVT mit einem offiziellen vdr noch in keinster Weise absehbar... Dito eine S2-taugliche DVB-API. Da kann man sich entweder dem Bazar-Prinzip anschliessen, darauf hoffen, dass sich alle einigen und damit verhungern oder eben selber was machen.
> Sie haben sich den vdr-1.4 geschnappt und für ihre Zwecke angepasst.
Klingt ja fast nach Kidnapping
> HD Aufnahmen werden im TS format aufgenommen, haben aber
> die endung *.vdr und das index File wird vermutlich auch nicht kompatibel sein.Es ist kompatibel zu den SD-Aufnahmen vom vdr-1.4, da macht HDTV ja keinen Unterschied. Das neue Indexformat vom 1.7er kam ja AFAIR erst dieses Jahr...
-
Vielleicht interessiert es ja jemanden:
Code
Alles anzeigenU-Boot 2008.10 (Sep 27 2009 - 22:34:55) ~ Reel Multimedia - NetClient NXP Semiconductors. - CX24XXX SoC with ARM1176JZF-S Chip: NEVIS Rev D DRAM: 384 MB Flash: 16 MB *** Warning - bad CRC, using default environment ~ Boot reached stage -60 In: serial Out: serial Err: serial PCI bridge init 00 0c 10ec 8167 0200 ff PCI done Decarm: spin Net: Boot reached stage 64 RTL-PHY-Version: 18000000 3/3 100% MAC 00264f0002b3 RTL8169#0: Auto-negotiation Enabled. RTL8169#0: 1000Mbps Full-duplex operation. Boot reached stage 65 RTL8169#0 Hit any key to stop autoboot: 0 Boot reached stage 1 Boot reached stage 6 Boot reached stage 14 Loading Kernel Image ... OK OK Boot reached stage 7 Boot reached stage 8 TAG_ADDRESS is at 0x17000000 before the kernel 0x17048000 Boot reached stage 15 Printing ATAG list at address 0x17000000 ATAG_TYPE: 0x54410001 - CORE Size : 0x0005 Data : 0x00000000, 0x00000000, 0x00000000, ATAG_TYPE: 0x54410007 - REVISION Size : 0x0003 Data : 0x00000001, ATAG_TYPE: 0x54410002 - MEMINFO Size : 0x0004 Data : 0x10000000, 0x00000000, ATAG_TYPE: 0x54410002 - MEMINFO Size : 0x0004 Data : 0x08000000, 0x10000000, ATAG_TYPE: 0x5441000a - MAC Size : 0x0004 Data : 0x00000000, 0x4be40000, ATAG_TYPE: END Starting kernel ... Starting Kernel ...at address 0x17048000 Linux version 2.6.18.5 (reel@RCsReelBox) (gcc version 4.1.1) #6 Wed Oct 28 15:24:44 CET 2009 CPU: Some Random V6 Processor [410fb764] revision 4 (ARMv6TEJ), cr=00c5387d Machine: Conexant Nocona IRD ChipID=0x245014f1 ChipRevID=0x30 EMAC address found in ATAG list ... Mac address bytes = 0x0 Mac address bytes = 0x0 Mac address bytes = 0x0 Mac address bytes = 0x0 Mac address bytes = 0x0 Mac address bytes = 0x0 Memory policy: ECC disabled, Data cache writeback INFO: Not reserving decarm memory CPU0: D VIPT write-back cache CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets Built 1 zonelists. Total pages: 98304 Kernel command line: console=ttyRI0 mtdparts=physmap-flash.0:0x20000@0x0(dummyboot)ro,0xe0000@0x20000(uboot),0x400000@0x100000(tlvkernel),0x400000@0x500000(rootfs) root=mtd3 rootfstype=jffs2 rw mem=384M init=/linuxrc PID hash table entries: 2048 (order: 11, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 384MB = 384MB total Memory: 181760KB available (2476K code, 486K data, 104K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 PCI: Conexant PCI Host Controller PCI: bus0: Fast back to back transfers disabled SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 16384 bind 8192) TCP reno registered audit: initializing netlink socket (disabled) audit(0.440:1): initialized JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) ttyRI0 at MMIO 0xe0412000 (irq = 2) is a CNXTUART RAMDISK driver initialized: 1 RAM disks of 16384K size 1024 blocksize loop: loaded (max 8 devices) r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded eth0: RTL8169 at 0x99850000, 00:26:4f:00:02:b3, IRQ 37 physmap platform flash device: 02000000 at f0000000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0040 physmap-flash.0: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. 4 cmdlinepart partitions found on MTD device physmap-flash.0 Creating 4 MTD partitions on "physmap-flash.0": 0x00000000-0x00020000 : "dummyboot" mtd: Giving out device 0 to dummyboot 0x00020000-0x00100000 : "uboot" mtd: Giving out device 1 to uboot 0x00100000-0x00500000 : "tlvkernel" mtd: Giving out device 2 to tlvkernel 0x00500000-0x00900000 : "rootfs" mtd: Giving out device 3 to rootfs platform cnxt0: conexant EHCI platform cnxt0: new USB bus registered, assigned bus number 1 platform cnxt0: irq 13, io mem 0xe8000100 platform cnxt0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected platform cnxt1: conexant EHCI platform cnxt1: new USB bus registered, assigned bus number 2 platform cnxt1: irq 17, io mem 0xe8001100 platform cnxt1: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected platform cnxt2: conexant EHCI platform cnxt2: new USB bus registered, assigned bus number 3 platform cnxt2: irq 20, io mem 0xe8002100 platform cnxt2: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 1 port detected usb 2-1: new high speed USB device using address 2 Initializing USB Mass Storage driver... usb 2-1: configuration #1 chosen from 1 choice hub 2-1:1.0: USB hub found hub 2-1:1.0: 4 ports detected usb 2-1.1: new high speed USB device using address 3 usb 2-1.1: configuration #1 chosen from 1 choice usb 2-1.2: new high speed USB device using address 4 usb 2-1.2: configuration #1 chosen from 1 choice scsi0 : SCSI emulation for USB Mass Storage devices scsi1 : SCSI emulation for USB Mass Storage devices usbcore: registered new driver usb-storage USB Mass Storage support registered. TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 NET: Registered protocol family 15 VFS: Mounted root (jffs2 filesystem). Freeing init memory: 104K Loading temporary / INIT for ReelBox, please wait... Vendor: Generic Model: Flash HS-CF Rev: 5.39 Type: Direct-Access ANSI SCSI revision: 00 sd 0:0:0:0: Attached scsi removable disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 Vendor: Generic Model: Flash HS-MS Rev: 5.39 Type: Direct-Access ANSI SCSI revision: 00 Vendor: Model: PILZ Rev: PMAP Type: Direct-Access ANSI SCSI revision: 00 sd 0:0:0:1: Attached scsi removable disk sdb sd 0:0:0:1: Attached scsi generic sg1 type 0 Vendor: Generic Model: Flash HS-SM Rev: 5.39 Type: Direct-Access ANSI SCSI revision: 00 sd 0:0:0:2: Attached scsi removable disk sdd sd 0:0:0:2: Attached scsi generic sg2 type 0 Vendor: Generic Model: Flash HS-SD/MMC Rev: 5.39 Type: Direct-Access ANSI SCSI revision: 00 sd 0:0:0:3: Attached scsi removable disk sde sd 0:0:0:3: Attached scsi generic sg3 type 0 SCSI device sdc: 3913728 512-byte hdwr sectors (2004 MB) sdc: Write Protect is off sdc: assuming drive cache: write through SCSI device sdc: 3913728 512-byte hdwr sectors (2004 MB) sdc: Write Protect is off sdc: assuming drive cache: write through sdc: sdc1 sd 1:0:0:0: Attached scsi removable disk sdc sd 1:0:0:0: Attached scsi generic sg4 type 0 waiting for USB devices: 0 Testing for device sdc1: kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. /dev/sdc1 is a valid boot device Testing for device sda1: mount: Mounting /dev/sda1 on /mnt failed: No medium found Testing for device sdb1: mount: Mounting /dev/sdb1 on /mnt failed: No medium found Testing for device sdd1: mount: Mounting /dev/sdd1 on /mnt failed: No medium found Testing for device sde1: mount: Mounting /dev/sde1 on /mnt failed: No medium found Valid boot devices: [1] USB Stick/HD on /dev/sdc1 (default) [2] NFS root on 192.168.0.200:/media/hd/lenny-armel-new ==> Press 'Enter' within 2 sec to stop init and enter a shell Your choice: [1] Rootdevice is: sdc1 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Mount failed for selinuxfs on /selinux: No such file or directory INIT: version 2.86 booting Running init.d/rc S
-
Tach!
Ich wollte mal kurz berichten.
Mein Netclient bootet jetzt sein rootfs von einem NFS-Server.
Ich arbeite momentan also auf dem Netclient quasi mit einem Debian Lenny für ARMEL.Den VDR-1.7.10 habe ich inzwischen kompiliert. Das Plugin "rbmini", das für die Ausgabe des OSDs und der AV-Daten ist, habe ich für 1.7.10 angepasst.
Es waren nur eine Hand voll Member-Funktionen, die Reel in die eigene OSD Klasse des Reel-VDR eingebaut hatte. Diese habe ich erstmal rausgenommen.Das rbmini-Plugin kompiliert also durch. Jetzt werde ich zum Testen erst einmal das MCLI-Plugin und das Streamdev-Plugin als Input-Devices einbauen.
Bin gespannt!
-
So. Das mcli-Plugin ist eingebaut.
Der VDR startet und ich sehe das OSD. Ich sehe auch EPG-Daten der Sendung die gerade läuft, aber kein Bild und kein Ton.
Stattdessen jede Menge:
Ich habe das rbmini-Plugin _ohne_ #define ALWAYS_TS übersetzt.
Kann mir jemand mal kurz erläutern, was momentan Stand der Dinge bei vdr-1.7.10 ist in Sachen der intern verwendeten Transport-Formate (TS/PES)? Reel hat das remux.c ja fast komplett umgeschrieben. Intern wird durch das #define ALWAYS_TS wohl nur noch TS benutzt. Wie ist das derzeit beim VDR-1.7.10?
-
So. Ich habe OSD, Bild und Ton.
Lüppt aber noch nicht ganz stabil. Muss noch etwas ändern.Dann kommt die Fernbedienung dran.
-
> Dann kommt die Fernbedienung dran.
Aus /dev/reeldrv kommt das Zeug prinzipiell im LIRC-Format raus (32Bit, 1us Einheiten, bit 24 ist mark/space). Da könnte man vermutlich auch direkt einen lircd dranklemmen, habs aber nicht probiert. Der wird dann wohl auch Probleme mit der Reel-FB haben, deren Kodierung ist recht seltsam. Ein passender Dekoder dazu ist aber in reelbox-control/frontpanel_nc.c.
-
Zitat
Originally posted by real_schorsch
> Dann kommt die Fernbedienung dran.Aus /dev/reeldrv kommt das Zeug prinzipiell im LIRC-Format raus (32Bit, 1us Einheiten, bit 24 ist mark/space). Da könnte man vermutlich auch direkt einen lircd dranklemmen, habs aber nicht probiert. Der wird dann wohl auch Probleme mit der Reel-FB haben, deren Kodierung ist recht seltsam. Ein passender Dekoder dazu ist aber in reelbox-control/frontpanel_nc.c.
Kann ich nicht einfach /dev/input/rbfp0 nehmen und dann das Remote-Plugin dazu?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!