Beiträge von Nano

So, bis jetzt rennt alles. Auch mit der Original-Fernbedienung.

Aufnahme und Wiedergabe funzt auch. Allerdings habe ich alte PES-Aufnahmen noch nicht getestet.
HD ist auch noch nicht getestet.

Das einzige Problem was ich derzeit habe, ist, dass ich bei der ARD Probleme mit dem AV-Sync habe.

Dec  4 17:49:50 ReelNetClient kernel: cnxt_rbm_drv  Delay due to video sync lost vs 1 as 1 vp 1 ap 1
Dec  4 17:49:51 ReelNetClient kernel: cnxt_rbm_drv  Delay due to video sync lost vs 1 as 0 vp 1 ap 1
Dec  4 17:49:59 ReelNetClient kernel: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Audio discontinue detected 6 15
Dec  4 17:49:59 ReelNetClient kernel: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Video discontinue detected 14 14
Dec  4 17:50:00 ReelNetClient kernel: cnxt_rbm_drv  Delay due to video sync lost vs 1 as 0 vp 1 ap 1
Dec  4 17:50:02 ReelNetClient kernel: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Video discontinue detected 15 2
Dec  4 17:50:02 ReelNetClient kernel: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Audio discontinue detected 13 0
Dec  4 17:50:02 ReelNetClient kernel: cnxt_rbm_drv  Delay due to video sync lost vs 1 as 1 vp 1 ap 1
Dec  4 17:50:03 ReelNetClient kernel: cnxt_rbm_drv set_av_mode pcr pid 0a6 video pid 0a6 Mpg2 audio pid 080 Mpa
Dec  4 17:50:03 ReelNetClient kernel: cnxt_rbm_drv HDMI mode 1 active 1 (tv_mode HDMI)
Dec  4 17:50:03 ReelNetClient kernel: CNXT_AUDIO_SYNC_WITH_PTS
Dec  4 17:50:03 ReelNetClient kernel: K:20999090:03:573 AUDIO: internal_audio_start() Format: 0x00000001
Dec  4 17:50:03 ReelNetClient kernel: cnxt_rbm_drv av_volume 0 -> -120000..0..5750 Mpa
Dec  4 17:50:03 ReelNetClient kernel: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Video discontinue detected 3 7
Dec  4 17:50:03 ReelNetClient kernel: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Audio discontinue detected 2 0
Dec  4 17:50:03 ReelNetClient kernel: cnxt_rbm_drv Video change dynamic (Source/PAL): x:720 y:576 ar: 4:3(1) fr: 25(2) d:1 de:0 -> HDMI Source PAL B WEUR(4)

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?

So. Ich habe OSD, Bild und Ton.
Lüppt aber noch nicht ganz stabil. Muss noch etwas ändern.

Dann kommt die Fernbedienung dran.

Ich schlage vor, dass wir die Diskussion um den Netclient hier weiter führen.

Ich habe übrigens erste Erfolge mit dem originalen VDR-1.7.10 auf dem Netclient.
Ich habe ein OSD, Bild und Ton.

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:

AddPacket: Buffer overflow!! 1048576 188 1048576

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?

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!

Vielleicht interessiert es ja jemanden:

U-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

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.

Zitat

Originally posted by Franzose
Hallo,

ich hätte da einmal eine Frage zum Netclient:

Was für eine Software läuft da drauf bzw. welche Oberfläche? Ist das etwas proprietäres von Reel oder die VDR-Software?

Kann man dort den original VDR aufspielen? Auf der AVG läuft ja VDR soweit ich weiß mit ein paar Modifikationen.

Vielleicht könnt ihr meine Verwirrung ein wenig aufklären.

Danke und Gruß

Alles anzeigen

Hallo!

Es wird evtl. Zeit, dass wir noch so einen Thread für den Netclient aufmachen.

Grob gesagt, läuft da quasi das gleiche wie auf der AVG. Also auch ein modifizierter VDR. Das Grundsystem ist Debian-like. Die Ausgabe der Video/Audio-Daten zum HW-Decoder erfolgt über ein spezielles Plugin, was ein Output-Device für VDR erzeugt. Der HW-Decoder kann laut Datenblatt H.264, VC-1 und MPEG2 verarbeiten.

Ich habe so ein Teil zuhause und spiele damit schon fleißig herum.
Da das Teil auch recht offen ist (bis auf die Kernel-Module für die HW-Anbindung) könnte man vermutlich tatsächlich einen eigenen VDR draufpacken. Zumal das ganze rootfs intern von einem USB-Stick läuft.
Also Reel-VDR Stick rausziehen und den Stick mit dem eigenen System reinstecken. NFS wird - so wie ich das sehe - auch unterstützt.

Prozessorplattform ist ARMEL.

NACHTRAG:
Entwicklungsumgebung hier:
http://wiki.reel-multimedia.co…ntwicklung#Reel_NetClient

Hallo,

ich wollte nur kurz bescheid geben, dass ich das Streaming-Tool netcv2dvbip für den Netceiver nochmals überarbeitet habe.
Unterstützt wird jetzt auch IGMPv2 und IGMPv1.

https://svn.baycom.de/repos/vdr-mcli-plugin/mcast/netcv2dvbip/

Außerdem ist jetzt auch das WIN32-Projekt-File unter "client/win32/visualstudio" zu finden.

https://svn.baycom.de/repos/vdr-mcli-plugin/mcast/common/win32/visualstudio/netcv2dvbip/

Viel Spass damit!

PS:
Seit letzter Woche habe ich endlich mein Netceiver-Gehäuse.
Seit gestern dann nach 8 Monaten endlich den Netclient.
Leider habe ich es gewagt, die Stromversorgung auszuschalten, während der Netclient im normalen Standby war. Jetzt sehe ich nur noch das Boot-Logo und er startet nicht mehr.
Jetzt darf ich nach einem Tag schon an den internen USB-Stick, um das Image neu zu flashen. Hoffentllich bringt das was............

Zitat

Originally posted by Razorblade

Ich dachte eher an das Streamformat, ich vermute mal Du schickst die MPEG-Header per RAW-UDP auf die Reise (H.610)? Wenn ja sollten das Häppchen à 188bytes sein, diese darf man aber zB laut DVB-IPTV Specs bis 7x188bytes aggregieren um mehr Durchsatz zu erreichen.

Ich nehme den TS, so wie er vom Netceiver kommt. Dann werden pro UDP-Paket 7 TS-Pakete verschickt. Nur die PAT wird neu generiert und enthält nur den Eintrag für die eine PMT des ausgwählten Programms.
Das habe ich alles von dvbfuse 1:1 übernommen.

Reines UDP ist ja laut DVB IPTV Spec.auch konform. Es muss nicht zwingend RTP sein.

Ich habe es übrigens bis jetzt nur mit VLC getestet. Bin gespannt auf Deine Tests mit dem IPTV-Plugin für VDR.

Was mich noch interessieren würde, wäre ein Plugin-Interface, so dass man ankommende TS über ein Plugin noch weiter behandeln könnte und danach weitersenden könnte. Man kann sich ja denken wofür...;)

Ich vermute nur, dass es für mich zu aufwendig ist. Vor allem, weil ja faktisch schon eine Lösung existiert. VDR+streamdev-Plugin(CVS mit IGMP)+böses Plugin

Ich habe ganz üble Bauchschmerzen, wenn ich mir die Zukunft von DVB in Sachen CI+ usw. anschaue. Vermutlich wird es da ja wohl nie ein CAM geben, was man in den Netceiver stecken kann, oder? Höchstens immer nur in jede einzelne Box.
Aber die Thematik hatten wir ja schon ein paar Seiten vorher...

In den letzten Wochen hat man aber recht häufig Meldungen darüber gelesen, dass immer mehr Netzbetreiber und HW-Hersteller auf diesen Zug aufspringen. Mich würde wirklich interessieren, wie zukunftsicher man mit der Reel Lösung in Anbetracht dieser Entwicklungen noch ist...
Es wäre wirklich schade drum...

Zitat

Originally posted by Razorblade
Nano: Gefällt mir echt gut, werde ich die Woche gleich mal testen (mit VLC und IPTV-Plugin als Clients)!
Hattest Du das mit den DVB-IPTV Specs im Hinterkopf geschrieben oder einfach so?

Gruß,
Razor

Ich hatte mir die DVB-IPTV Specs mal angeschaut. Im Wesentlichen ging es dort aber nur um die ganze Verwaltung drumherum. Ich glaube, das meinte realschorsch auch mit "Moloch".

Vielleicht hat ja nun jemand Lust, das ganze Service Discovery zu machen? Stichworte sind hier: DVBSTP, SD&S, XML.

Hier wird das Metadaten-Server genannt:
http://www.irt.de/webarchiv/sh…=MzQzMCMxMDA0MjEzMTAjcGRm

Laut DVB-IPTV gibt es übrigens zwei erlaubte Arten, Metadaten zu transportien, entweder im TS oder in den SD&S XML Strukturen.
Mit dem Tool wird die erste Lösung realisiert, ist ja eh schon so vorhanden.

Momentan räume ich noch weiter den Code auf und mache es etwas sicherer in Bezug auf die Bedienung. Wenn alles korrekt sein soll, müsste wohl auch IGMPv1 und IGMPv2 noch mit unterstützt werden.
Außerdem gibt wohl Settop-Boxen, die nur max. IGMPv2 sprechen.

Gruß
Nano

Kleines Update:

Das Projekt steht nun auch auf dem Baycom SVN Server zur Verfügung.
Momentan überarbeite ich das Tool noch ein wenig. Änderungen stehen dann über das Repository zur Verfügung.

Hallo!

Hier die erste Version des OnDemand Multicast Streamers für den Netceiver. Das Projekt-File für Visual C++2008 kommt morgen.

---

HOWTO - netcv2dvbip

1)

svn co https://svn.baycom.de/repos/vdr-mcli-plugin/mcast/

2)

wget http://www.vdr-portal.de/board/attachment.php?attachmentid=22992 
mv attachment.php?attachmentid=22992 netcv2dvbip-0.0.1.tar.bz2

3)

cd mcast
tar xfj ../netcv2dvbip-0.0.1.tar.bz2
cd ..

4)

cd client
make
cd ..

5)

cd netcv2dvbip
make

6)

./netcv2dvbip -b <ip_address of streaming interface> -i <interface with netceiver network>

Hallo!

Im Elektor-Newsletter steht, dass Farnell Cadsoft gekauft hat.
http://www.elektor.de/elektron…l-verkauft!.1087464.lynkx

Dann hat Klaus ja jetzt richtig viel Zeit für sein Hobby.

Zur Info:

Das Netceiver-Gehäuse Kit ist nun offensichtlich auch im Online-Shop bestellbar. Zu finden unter "Zubehör" für 109,-EUR.

Zitat

* Gehäuse-Deckel & Gehäuseboden
* 60W Tischnetzteil inkl. Power Adapter

Hab' gerade direkt bestellt. Soll dann auch in 4 Wochen - Mitte Oktober - verfügbar sein so wie das Netceiver-Komplettpaket.

Hoffentlich wird das mit dem Netclient auch mal langsam was.

Gruß
Nano

Hi!

Wollte nur mal kurz becheid geben, dass das IPTV per IGMP nicht eingeschlafen ist. Bin nur seit dem 02.09. im Urlaub und komme erst am 17.09. wieder nach DE.

Unterstuetzt wird uebrigens erst mal nur IGMP V3.
Die aktuelle CVS-Version des Streamdev-Plugins kann uebrigens auch per IGMP V1&V2 streamen. Ich habe mich dort ordentlich am Code bedient.

Warum nur IGMP V3? Weil dort alle Membership Reports an die eine zentrale Multicast Adresse 224.0.0.22 gehen. Bei V1&V2 muss der Server/Router per setsockopt( JOIN_MULTICAST_GROUP ) in jede Gruppe eintreten, um dort auch die Reports zu empfangen. Koennte man vermutlich zwar auch mit dem Promisc Modus und der libpcap machen, ist aber dann eine Abhaenigkeit mehr. Aktuelle Kernel und mind. Windows XP sprechen eh IGMP V3 per default.

Es funktioniert momentan schon recht gut und recht fix. Getestet mit VLC unter Windows und dem ncv2iptv Tool unter Linux.

BTW: Hat mal jemand einen Namensvorschlag fuer das Teil? netcv2iptv? ncv2iptv? dvbiptv?

Gruss
Nano

Zitat

Original von Razorblade

Genau dieses Scenario würde mich interessieren, ich habe im Moment einen Netceiver an einem isolierten Netz an meinem vdr (server, recording only) mit eth1 und den Rest des LANs (inkl. zwei vdr frontends die wiederum auch ein zweites eth ins Netceiver Netz haben).
Wünschen würde ich mir einen simplen Netceiver to DVB-IPTV Konverter (auf Linux) und dann die vdr's nur noch im regulären LAN zu haben (dann vermutlich mit IPTV Plugin anstatt mcli)

Ja genau das wird es auch sein. Das Teil soll unter Windows und Linux laufen. Es wird ein einfaches Konsolen-Tool. Für den Betrieb unter Windows möchte ich aber auf jeden Fall die Möglichkeit haben, dass die generierten Multicasts nicht wieder ins LAN geblasen werden. Dank Detis Hinweis, werde ich diesen MS Loopback Adapter mal installieren, mit dem das hoffentlich klappt. Dann kann man auch dieses DVBLogic DVBLInk IPTV unter Vista bzw. Win7 benutzen.

Mit dem Tools sind dann folgende Konstellationen möglich:
1) Netceiver ---ipv6---> eth0#Linux-Server mit Tool###eth1 ---ipv4---> Clients

2) Netceiver ---ipv6---> eth0#Client mit Tool#lo ---ipv4---> App auf Client

deti:

Ah cool! Danke für den Hinweis!
Sobald ich alles aufgeräumt habe, werde ich den Code hier zur Verfügung stellen.

Tach!

Kurzer Zwischenbericht von mir:
Ich wollte ja möglichst einfach unter Windows den Netceiver nutzbar machen.

Ich habe jetzt ein kleines Tool gebaut, was auf lokale IGMP (IPv4) hört und dann entsprechend einen lokalen TS-über-UDP Stream zur Verfügung stellt oder ggf. wieder stoppt.

Eine Multicast-Adresse der Form 239.0.0.1 entspricht dabei Kanal 1.
239.0.0.2 entspricht dabei Kanal 2, usw.

Also kann man mit udp://239.0.x.y jeden Kanal zwischen 1-65534 erreichen.
Der Port ist dann immer gleich.

Getestet mit VLC. Muss jetzt noch alles schön machen.

UPDATE: Zu früh gefreut!

Zwei RIESIGE Nachteile:
1) Das Multicasten klappt nicht auf dem Loopback-IF.
2) Aufgrund von 1) muss ein echtes IF genommen, was dann auch alle
Pakete an das angeschlossene LAN raushaut. SHIT!

Dann muss ich jetzt wohl doch HTTP einbauen. Grmpf.

Die Multicast-Geschichte ließe sich aber für den Fall nutzen, wenn man den Netceiver direkt an den Server-PC dranhängt, der dann mit meinem Tool die UDP Multicasts über ein anderes IF für das LAN bereitstellt. Quasi als DVB-IPTV Head. Dann wird das LAN nicht doppelt mit den Multicasts belastet. Oder man arbeitet mit VLAN und entsprechenden Switches, die nur an den gewünschten Endgeräten jeweils die nativen IPv6 Multicasts de Netceivers zur Verfügung stellen.

Gruß
Nano