Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Nachrichten - flo

Seiten: [1] 2
1
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juli 29, 2017, 10:19:15 Nachmittag »
Leider immer noch nicht.

Der neuere Dongle (1.3.1) hat scheinbar ein technisches Problem das ich nicht finden kann.
Ich habe jetzt ein paar Tage die Dongels an einem rpi und einem normalen Rechner gehabt.
Der neuere Dongle will immer wieder mal zickig sein.
Mit sundek.conf oder ohne ist wurscht. Es Ruckelt nur an dem einem Dongel.

Was für Möglichkeiten habe ich oder sollte ich ihn zurück schicken?

LG Florian


Code: [Auswählen]
cat /etc/sundtek.conf
-->--
# For rpi
# /opt/bin/mediaclient -P on -d /dev/dvb/adapter0/frontend0
# http://support.sundtek.com/index.php/topic,1573.0.html
use_hwpidfilter=on

# http://support.sundtek.com/index.php/topic,2215.0.html
support_mmap=on

device_attach=service vdr restart
--<--

2
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juli 12, 2017, 11:01:08 Nachmittag »
Zitat von: Sundtek am Juli 03, 2017, 10:38:10 Nachmittag
Abhilfe geschaffen bei Problemen auf 114 MHz.

Gesagt, getan und für erledigt erklärt  ;D

Andere frage: Metallgehäuse für de rpi ?
Mich wundert es dennoch das es ohne Änderungen des Standortes plötzlich deutliche Fehler gibt. Wenn auch Techniker, kein Elektroniker :)

3
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juli 04, 2017, 11:21:32 Nachmittag »
Zitat von: Sundtek am Juli 03, 2017, 10:38:10 Nachmittag
Das ist doch n Raspberry PI? Nimm n längeres USB Kabel das du die Tuner weiter wegbekommst vom Raspberry.

Kommt wohl auf mehrere Faktoren an es wurde schon mehrfach erwähnt im Forum und ein längeres USB Kabel hat -- im Fehlerfall --
 immer Abhilfe geschaffen bei Problemen auf 114 MHz.
Huch ??? ... danke, ich schau mal! melde mich :-D

4
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juli 03, 2017, 08:36:35 Nachmittag »
Zitat von: Sundtek am Juni 30, 2017, 10:42:55 Nachmittag
/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 zeigt dir die Signalstatistik an.
Danke

Was sagt mir das?:
Code: [Auswählen]
SIGNAL: [.............................    ] ( 88%) BER:      0 CNR: 36,70 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.............................    ] ( 88%) BER:      1 CNR: 35,70 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
Einziger grober unterschied hin und wieder BER 1 vs. 0
Bei 1 scheinen Fehler und das Ruckeln erkennbar zu sein. Beide dongels gleichzeitig. :?/
Nachtrag: Weder noch nicht zu 100% feststellbar... Woran denn? CNR?

Gibt es Hinweise wie ich dem auf die schliche kommen kann?
Gemäss der Empfangsstärke sollte alles klappen es sei denn das signal kommt von kabeldeutschland bereits so bei mir defekt an. Wie kann ich all diese Sachen testen?  ???

Gruß Florian


5
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 30, 2017, 08:37:37 Nachmittag »
Zitat von: Sundtek am Juni 18, 2017, 02:28:08 Nachmittag
/etc/sundtek.conf
device_attach=service tvheadend restart
Danke, guter Hinweis. Bringt aber nix in meinem Fall. (ich bleib aber beim VDR!)

Habe wieder eine weitere Version runter gespielt und HD ist derzeit zickig. Bild bleibt ein zwei sekunden stehen und wie immer: Nix in den syslog, dmesg etc. boa... das nervt :)
 
Langsam bekomme ich den Eindruck als würde einer meiner Dongels spinnen: 1.2.1 und 1.3.1 sind im Spiel.
Wie kann ich herausfinden welcher Dongel was macht? mediaclient --lc reicht nicht :/

Lg Florian

6
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 18, 2017, 12:22:51 Nachmittag »
Zitat von: flo am Juni 17, 2017, 08:35:52 Nachmittag
Zitat von: Sundtek am Juni 14, 2017, 10:58:28 Nachmittag
Wenn Du schon am Testen bist, kannst Du das auch testen:
support_mmap=on (in /etc/sundtek.conf)?

Führt das noch immer zu Störungen auf dem ARM? Auf Intel Systemen klappt's soweit.
Teil 1+2
https://github.com/Hexxeh/rpi-firmware/issues/151#issuecomment-307776323

Neuere Kernels machen es zickiger. Es sind zwar derzeit keine mem Fehler mehr aufgetreten aber das ist vermutlich eine Zeitfrage.
Ich bin raus mit testen. Der besagt Kernel, s.o. oder im link, läuft erst einmal.
LG

7
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 17, 2017, 08:35:52 Nachmittag »
Zitat von: Sundtek am Juni 14, 2017, 10:58:28 Nachmittag
Wenn Du schon am Testen bist, kannst Du das auch testen:
support_mmap=on (in /etc/sundtek.conf)?

Führt das noch immer zu Störungen auf dem ARM? Auf Intel Systemen klappt's soweit.

:)

Bisher find ich nichts was die Einstellung pro/contra bewirkt. Ist drin mit keiner Veränderung/ Auffälligkeit.

Teil 1:
https://github.com/Hexxeh/rpi-firmware/issues/151#issuecomment-307776323

:)

8
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 14, 2017, 10:31:59 Nachmittag »
Zitat von: Sundtek am Juni 12, 2017, 03:10:23 Vormittag
Sollte das Problem weiter auftreten melde dich einfach via Chat...

Danke! Der Kernel tuts. Hab die rpi Leute in github via "issue" bereits informiert und wir gehen die kernels gerade durch :)

LG Florian

9
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 11, 2017, 10:07:17 Nachmittag »
Danke allen für Hinweise!

rpi-update auf f4cb84915874f32d88e2bfe793620d7afe25c755 hats gebracht. Kernel von ca. 03/2017 lässt wieder alles zu... für sundtek treiber und vdr zumindest :)
Kernel Linux pi2 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux

Ticket kann geschlossen werden.

LG Florian

10
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 11, 2017, 08:37:51 Nachmittag »
Zitat von: Sundtek am Juni 11, 2017, 08:08:46 Nachmittag
Du kannst folgenden Eintrag versuchen:
/etc/sundtek.conf
support_mmap=on

Was tut das? Finde nichts in --help / hier im Forum ??
LG Florian

11
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 11, 2017, 08:23:24 Nachmittag »
Hi!

Danke für Info, das hat meinen verdacht bestätigt :)
swap wurde von rasbian angelegt.. tiefergehend habe ich keine Erfahrungen/ Wissen. :(

Aber: Nach dem ich das gefährliche "rpi-update" durchführte und nun eine neue Kernel Version ist das verhalten ein wenig besser. Ich bleib drann!

LG Florian

12
Treiber / Re:Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 11, 2017, 07:57:40 Nachmittag »
Hi, danke für Info!
htop ist in Verwendung ~200M von 900M in use, swap 18MB von 2G.... ich tippe auf den kernel der vermutlich zu neu ist , kann es nicht einschätzen.

13
Treiber / Seit ca. 14 tagen probleme. Ursache: Treiber problem?
« am: Juni 11, 2017, 06:30:14 Nachmittag »
Zitat von: Sundtek am April 14, 2014, 08:32:13 Nachmittag
NetInstall (alle Systeme): http://www.sundtek.de/media/sundtek_netinst.sh (empfohlen) (70 KByte)
Aktuell installiert.

Hi,
seit ein paar Tagen (ca. zwei Wochen) spinnen meine TV Aufnamen. Es "Ruckelt". Zeitweise scheint es so als wäre kein Empfang vorhanden. Auch streams via vdr stream.



Syslog meldet allerdings nun endlich mal etwas brauchbares [1].

System: rpi 2, sundtek dongels 1.2.1 und 1.3.1 via DVBC



[1]
Code: [Auswählen]
Jun 11 17:54:05 pi2 recordingaction[2304]: executing /usr/share/vdr/recording-hooks/R90.custom before recording /media/recordings/vdr/test/ZDF2/2017-06-11.17.00.3-0.rec as shell script
Jun 11 17:54:05 pi2 vdr[2227]: [2227] record /media/recordings/vdr/test/ZDF2/2017-06-11.17.00.3-0.rec
Jun 11 17:54:07 pi2 vdr[2227]: [2306] executing '/usr/lib/vdr/vdr-recordingaction started "/media/recordings/vdr/test/ZDF2/2017-06-11.17.00.3-0.rec"'
Jun 11 17:54:07 pi2 recordingaction[2314]: executing /usr/share/vdr/recording-hooks/R90.custom  as shell script
... some timer ....
Jun 11 17:54:20 pi2 kernel: mediasrv: page allocation failure: order:4, mode:0x24040c0(GFP_KERNEL|__GFP_COMP)
Jun 11 17:54:20 pi2 kernel: CPU: 3 PID: 2132 Comm: mediasrv Not tainted 4.9.24-v7+ #993
Jun 11 17:54:20 pi2 kernel: Hardware name: BCM2835
Jun 11 17:54:20 pi2 kernel: [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24)
Jun 11 17:54:20 pi2 kernel: [<8010c058>] (show_stack) from [<80455200>] (dump_stack+0xd4/0x118)
Jun 11 17:54:20 pi2 kernel: [<80455200>] (dump_stack) from [<80214b3c>] (warn_alloc+0x10c/0x120)
Jun 11 17:54:20 pi2 kernel: [<80214b3c>] (warn_alloc) from [<8021504c>] (__alloc_pages_nodemask+0x450/0xdd0)
Jun 11 17:54:20 pi2 kernel: [<8021504c>] (__alloc_pages_nodemask) from [<80234cfc>] (kmalloc_order+0x28/0x78)
Jun 11 17:54:20 pi2 kernel: [<80234cfc>] (kmalloc_order) from [<80234d78>] (kmalloc_order_trace+0x2c/0xd0)
Jun 11 17:54:20 pi2 kernel: [<80234d78>] (kmalloc_order_trace) from [<8025ddd8>] (__kmalloc+0x218/0x274)
Jun 11 17:54:20 pi2 kernel: [<8025ddd8>] (__kmalloc) from [<80565fd8>] (proc_do_submiturb+0xd74/0xeac)
Jun 11 17:54:20 pi2 kernel: [<80565fd8>] (proc_do_submiturb) from [<80566978>] (usbdev_ioctl+0x868/0x1aa0)
Jun 11 17:54:20 pi2 kernel: [<80566978>] (usbdev_ioctl) from [<802831cc>] (do_vfs_ioctl+0xac/0x820)
Jun 11 17:54:20 pi2 kernel: [<802831cc>] (do_vfs_ioctl) from [<80283984>] (SyS_ioctl+0x44/0x6c)
Jun 11 17:54:20 pi2 kernel: [<80283984>] (SyS_ioctl) from [<801080c0>] (ret_fast_syscall+0x0/0x1c)
Jun 11 17:54:20 pi2 kernel: Mem-Info:
Jun 11 17:54:20 pi2 kernel: active_anon:48543 inactive_anon:15851 isolated_anon:0
 active_file:86662 inactive_file:54272 isolated_file:0
 unevictable:2 dirty:332 writeback:0 unstable:9000
 slab_reclaimable:13600 slab_unreclaimable:7130
 mapped:15962 shmem:11410 pagetables:567 bounce:0
 free:5398 free_pcp:243 free_cma:0
Jun 11 17:54:20 pi2 kernel: Node 0 active_anon:194928kB inactive_anon:63404kB active_file:346656kB inactive_file:217076kB unevictable:8kB isolated(anon):0kB isolated(file):0kB mapped:63856kB dirty:1328kB writeback:0kB shmem:45640kB writeback_tmp:0kB unstable:36000kB pages_scanned:0 all_unreclaimable? no
Jun 11 17:54:20 pi2 kernel: Normal free:20844kB min:3868kB low:4832kB high:5796kB active_anon:194936kB inactive_anon:63404kB active_file:346676kB inactive_file:217256kB unevictable:8kB writepending:1624kB present:966656kB managed:945524kB mlocked:8kB slab_reclaimable:54400kB slab_unreclaimable:28520kB kernel_stack:1384kB pagetables:2268kB bounce:0kB free_pcp:600kB local_pcp:0kB free_cma:0kB
Jun 11 17:54:21 pi2 kernel: lowmem_reserve[]: 0 0
Jun 11 17:54:21 pi2 kernel: Normal: 388*4kB (MH) 196*8kB (UEH) 529*16kB (UH) 210*32kB (UEH) 4*64kB (H) 1*128kB (H) 0*256kB 0*512kB 1*1024kB (H) 0*2048kB 0*4096kB = 19712kB
Jun 11 17:54:21 pi2 kernel: 152624 total pagecache pages
Jun 11 17:54:21 pi2 kernel: 169 pages in swap cache
Jun 11 17:54:21 pi2 kernel: Swap cache stats: add 3875, delete 3706, find 806/911
Jun 11 17:54:21 pi2 kernel: Free swap  = 1896652kB
Jun 11 17:54:21 pi2 kernel: Total swap = 1910780kB
Jun 11 17:54:21 pi2 kernel: 241664 pages RAM
Jun 11 17:54:21 pi2 kernel: 0 pages HighMem/MovableOnly
Jun 11 17:54:21 pi2 kernel: 5283 pages reserved
Jun 11 17:54:21 pi2 kernel: 2048 pages cma reserved
-- weitere vdr status logs ---

Danke für info, feedback zur möglichen Lösung :)

LG Florian

14
Treiber / Re:Linux Treiber 27. März 2017
« am: April 02, 2017, 10:23:34 Vormittag »

Zitat von: Sundtek am April 01, 2017, 01:21:29 Nachmittag
Es reicht vollkommen den Tuner auf DVB-T zu setzen

/opt/bin/mediaclient -D DVBT -d /dev/dvb/adapter0/frontend0

Danke für Feedback

Bei mir nicht !?:
/opt/bin/mediaclient -D DVBT  --> w_scan: no matches
/opt/bin/mediaclient -D DVBT2 --> w_scan: matches
:/
"DVBT2" war nur auf verdacht, ist nicht dokumentiert!
Und daher sind die Möglichkeiten die --help liefert weniger eine Hilfe.

LG Florian

15
Treiber / Feedback: Re:Linux Treiber 27. März 2017
« am: April 01, 2017, 01:14:16 Nachmittag »
Zitat von: Sundtek am April 14, 2014, 08:32:13 Nachmittag
Debian/Ubuntu: http://sundtek.de/media/sundtek-netinst-driver.deb (850 Byte)

Feedback:

Doks sind unvollständig!
# /opt/bin/mediaclient --help

# DVB-T2 "anwerfen": Tut nix
/opt/bin/mediaclient --device=/dev/dvb/adapter0/frontend0 --mode=DVBT2 --setdtvmode=DVBT

# Undokumentiert, auf verdacht: Tut auch nix
/opt/bin/mediaclient --device=/dev/dvb/adapter0/frontend0 --mode=DVBT2 --setdtvmode=DVBT2

# Undokumentiert: Tut nix
/opt/bin/mediaclient --device=/dev/dvb/adapter0/frontend0 --setdtvmode=DVBT2

# Warum jetzt erst?
-->--
/opt/bin/mediaclient --setdtvmode=DVBT2
Using device: /dev/dvb/adapter0/frontend0
Setting Frontend Properties to: DVBT2
Done.
--<--

# Erfolgsmeldung oder nicht? "." vs. "Done." ?:
-->--
/opt/bin/mediaclient --mode=DVBT2
Using device: /dev/dvb/adapter0/frontend0
.
--<--


Darf gerne mal überholt werden ;)
Dannach schafft w_scan auch was :)

Seiten: [1] 2