Bin ich da wirklich der einzige bei dem der Effekt auftritt hat, oder der einzige den das stört?
Nein, ähnliches habe ich auch unter vdr-1.7.31 und der Ausgabe auf eine SD-FF Karte beobachtet...
Bin ich da wirklich der einzige bei dem der Effekt auftritt hat, oder der einzige den das stört?
Nein, ähnliches habe ich auch unter vdr-1.7.31 und der Ausgabe auf eine SD-FF Karte beobachtet...
Jan 6 18:35:04 odin vdr: [11253] ERROR: /vdr/services/vdr/current/PLUGINS/lib/libvdr-streamdev-server.so.1.7.35: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
=> Das sollte doch im Makefile stehen, oder mach ich was falsch ? Bin ich der einzige der diesen Fehler hat ?
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
Zum Quick&Dirty-Kompilieren habe im streamdev-Plugin das Makefile, wie folgt angepasst
diff --git a/Makefile b/Makefile
index b375844..3821eb9 100644
--- a/Makefile
+++ b/Makefile
@@ -33,9 +33,9 @@ TSPLAYVERSNUM = $(shell grep 'define TSPLAY_PATCH_VERSION ' $(VDRDIR)/device.h |
### Allow user defined options to overwrite defaults:
-ifeq ($(shell test $(APIVERSNUM) -ge 10713; echo $$?),0)
-include $(VDRDIR)/Make.global
-else
+#ifeq ($(shell test $(APIVERSNUM) -ge 10713; echo $$?),0)
+#include $(VDRDIR)/Make.global
+#else
ifeq ($(shell test $(APIVERSNUM) -ge 10704 -o -n "$(TSPLAYVERSNUM)" ; echo $$?),0)
DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
CFLAGS += -fPIC
@@ -44,7 +44,7 @@ else
CFLAGS += -fPIC
CXXFLAGS += -fPIC
endif
-endif
+#endif
Alles anzeigen
Sicher das folgendes Richtig ist ?
+DEFINES += -DLIRC_DEVICE=\"$(LIRC_DEVICE)\"../../lib
Hier baut es auch erst nach folgenden "Hotfix" und nach eines Kopieren/Linken der Datei "gruel_common.i"
--- ./lib/howto_fib_crc16_vbb.cc.org 2011-08-08 15:39:27.000000000 +0200
+++ ./lib/howto_fib_crc16_vbb.cc 2012-11-18 14:05:51.847345946 +0100
@@ -94,7 +94,8 @@
while (input_used_counter < input_samples && output_generated_counter<noutput_items)
{
Summe =0;
- CRC = {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};
+ for(f=0;f<15;f++)
+ CRC[f] = 1;
memcpy(&d_DataVector[0], &in[0], sizeof (char)*(d_InVectorSize-16)); // Daten uebernehmen
for(i=(d_InVectorSize-16);i<d_InVectorSize;i++) d_DataVector[i] = in[i] ^ 1; // Zweikomplement des CRCs bilden und anhaengen
Alles anzeigen
#> ln -s /usr/include/gruel/swig/gruel_common.i /usr/include/gnuradio/swig/gruel_common.i
Siehe auch http://www.ruby-forum.com/topic/4040797
#> apt-get install gnuradio-dev libcppunit-dev libgnuradio-core3.5.3.2 swig
#> autoreconf -i
#> ./configure
#> make
@andr: rtl_fm funktioniert doch ganz passabel, wenn man -W für Wide FM mit angibt.
Danke für den Hinweis, mein "Checkout" ist wohl zu alt gewesen, verantwortlich ist wohl der Commit vom 23.10.2012 (http://cgit.osmocom.org/cgit/r…7f186e19746658ade01632589)
kann jemand etwas zu dem in Linux verfügbaren Noxon Treiber sagen? Lassen sich damit DAB Kanäle tunen, also bekommt man einen Lock auf den entsprechenden Frequenzen?
Die regulär verfügbaren Kernel-Treiber unterstützen nur den DVB-T Empfang.
Mit rtl-sdr kommt man aber an die Rohdaten des Frequenzspektrum, die der Tuner empfängt.
Die UKW Dekodierung per rtl_fm (rtl-sdr) FM-Empfang funktioniert leider nur leidlich.
Mit der multimode RX (GNU-Radio Skript) , sowie gqrx (Standalone GUI) über rtl_tcp (rtl-sdr) funktioniert der FM-Empfang per SDR ganz brauchbar.
Ein funktionierende DAB+ Dekoder ist mir aber noch nicht über den Weg gelaufen.
Per Google habe ich bisher nur eine Diplomarbeit für DAB (ohne Plus aber mit Quellcode) "http://www.zsn.zhaw.ch/fileadmin/user_upload/engineering/_Institute_und_Zentren/ZSN/Projekte/dab/Documentation.pdf" gefunden.
Dort wird GNU-Radio als Framework verwendet, theoretisch müsste rtl-sdr nur als Frontend-Plugin geladen werden.
Edit Vielleicht bietet das folgende GNU-Radio-Projekt einen Ansatz : https://www.cgran.org/browser/projects/dabp/trunk
Es wurde aber seit 2 Jahren nicht mehr angefasst und letzter Checkin sagt nur "Testing. Not working yet. Aber es wird mplayer als dekoder verwendet.
Zitatthis is to test the gr-dabp package for MSC
to pipe to mplayer using
./app_dabp_msc -i subchid -n channel.conf infile | mplayer -ac faad -rawaudio format=0xff -demuxer rawaudio -
this is to tell mplayer that this is a raw AAC (ADTS) audio stream and to use faad codec
....
An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)
wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
Ich habe wheezy mit kernel 3.2.0-4 installiert.
Hat jemand eine Idee, woran das liegen könnte?
Ich weiß nicht, ob es das gleiche Problem ist, aber bei mir hatte der Timercode von LCD4Linux ebenfalls Probleme.
Hintergrund bei mir, die Dockstar hat kein RTC. Damit startet die Uhr immer mit dem 1.1.1970 und wird erst Sekunden später
per NTP aktualisiert, wenn das Netzwerk online ist. Der Orignalkode von LCD4Linux kommt aber mit einem so langen Zeitsprung
nicht klar. Ich habe dies für mich, wie folgt behoben, den Patch aber nie Upstream für eine Review gesendet.
--- timer.c (Revision 1144)
+++ timer.c (Arbeitskopie)
@@ -152,16 +152,27 @@
/* calculate time difference between the last time the timer has
been processed and the next time it will be processed */
int interval = Timers[timer].interval * number_of_intervals;
+ if(number_of_intervals < 0 || number_of_intervals > 3) {
+ /* convert time difference (in milliseconds) to a "timeval"
+ struct (in seconds and microseconds) */
+ struct timeval tv_interval = {
+ .tv_sec = Timers[timer].interval / 1000,
+ .tv_usec = (Timers[timer].interval % 1000) * 1000
+ };
- /* convert time difference (in milliseconds) to a "timeval"
- struct (in seconds and microseconds) */
- struct timeval tv_interval = {
- .tv_sec = interval / 1000,
- .tv_usec = (interval % 1000) * 1000
- };
+ /* finally, add time difference to the timer's trigger */
+ timeradd(now, &tv_interval, &Timers[timer].when);
+ } else {
+ /* convert time difference (in milliseconds) to a "timeval"
+ struct (in seconds and microseconds) */
+ struct timeval tv_interval = {
+ .tv_sec = interval / 1000,
+ .tv_usec = (interval % 1000) * 1000
+ };
- /* finally, add time difference to the timer's trigger */
- timeradd(&Timers[timer].when, &tv_interval, &Timers[timer].when);
+ /* finally, add time difference to the timer's trigger */
+ timeradd(&Timers[timer].when, &tv_interval, &Timers[timer].when);
+ }
}
@@ -456,6 +467,7 @@
/* if there is a notable difference between "time_difference" and
the next upcoming timer's interval, assume clock skew */
if (time_difference > (Timers[next_timer].interval + CLOCK_SKEW_DETECT_TIME_IN_MS)) {
+
/* extract clock skew from "time_difference" by eliminating
the timer's triggering interval */
int skew = time_difference - Timers[next_timer].interval;
@@ -465,10 +477,10 @@
/* convert clock skew from milliseconds to "timeval"
structure */
- struct timeval clock_skew = {
- .tv_sec = skew / 1000,
- .tv_usec = (skew % 1000) * 1000
- };
+ //struct timeval clock_skew = {
+ //.tv_sec = skew / 1000,
+ //.tv_usec = (skew % 1000) * 1000
+ //};
/* process all timers */
for (timer = 0; timer < nTimers; timer++) {
@@ -477,9 +489,21 @@
continue;
/* correct timer's time stamp by clock skew */
- timersub(&Timers[timer].when, &clock_skew, &Timers[timer].when);
+ //timersub(&Timers[timer].when, &clock_skew, &Timers[timer].when);
+
+ /* convert time difference (in milliseconds) to a "timeval"
+ struct (in seconds and microseconds) */
+ struct timeval tv_interval = {
+ .tv_sec = Timers[timer].interval / 1000,
+ .tv_usec = (Timers[timer].interval % 1000) * 1000
+ };
+
+ /* finally, add time difference to the timer's trigger */
+ timeradd(&now, &tv_interval, &Timers[timer].when);
+
}
+
/* finally, zero "diff" so the next update is triggered
immediately */
timerclear(&diff);
Alles anzeigen
Hi,
irgendwie driftet das Thema ab, das Problem ist doch eigentlich das Schnittmarken (marks), die nicht auf einen I-Frame sitzen sich nicht mehr nachträglich bearbeiten lassen, hier sollte der VDR erst mal toleranter werden.
Andreas
Hi,
ja, ist hier auch so, wenn die Schnittmarke nicht auf einem I-Frame liegt, lässt sie sich nicht verschieben.
Das Problem ist aber schon alt, unter vdr 1.6 hatte ich mir mit folgenden Perl Script geholfen.
Er verschiebt alle Marken auf das nächste I-Frame. (Aber kann halt nur das alte VDR-Format fixen)
# cat /opt/vdr/bin/fixmarks.pl
#!/usr/bin/perl
use strict;
use warnings;
my $debug = 0;
my $recording;
my $marks;
my %Iframes;
sub read_marks_file {
my $marks_file = shift;
open MFH, "$marks_file" || die "Could not open marks.vdr";
@{$marks} = ();
my @raw_marks = <MFH>;
foreach (@raw_marks) {
chomp $_;
$_ = (split /\s/, $_)[0];
if ($_ !~ /^\d{1,2}:\d{1,2}:\d{1,2}\.\d{1,2}$/) {
print("Could not read mark $_, skipping\n");
next;
}
my ($h,$m,$s,$f) = split /[:.]/,$_;
my $frame = ($h * 3600 + $m * 60 + $s)* 25 + $f;
my $real_frame = (find_realframe($frame))[0];
my $real_mark = frames2mark($real_frame);
if ($real_mark ne "-1") {
push @{$marks}, $real_mark;
}
}
}
sub find_realframe{
my $frame = int (shift);
#print "got frame $frame\n";
if ($Iframes{$frame}) {
return ($frame, $Iframes{$frame});
}
my $return_frame = 0;
my $i = 1;
while ((! $return_frame) && ($i < 10)) {
if ($Iframes{$frame - $i}) {
print( "Frame $i frames before $frame is an I-Frame.\n");
print( "Returning " . ($frame - $i) . " " .$Iframes{$frame - $i} . "\n") if $debug;
return ($frame - $i , $Iframes{$frame - $i});
}
elsif ($Iframes{$frame + $i}) {
print( "Frame $i frames behind $frame is an I-Frame\n");
print( "Returning " . ($frame + $i) . " " .$Iframes{$frame + $i} . "\n") if $debug;
return ($frame + $i , $Iframes{$frame + $i});
}
else {
print( "no iframe found in $i frame distance\n") if $debug;
$i++;
}
}
die "could not find a reasonably positioned iframe, exiting\n";
};
sub save_marks_file {
my $marks_file = shift;
if (-e "$marks_file") {
my $err = system (sprintf("mv '%s' '%s~'",$marks_file,$marks_file));
if ($err) {die "Something happend while backing up original mark file: $!...\n";}
}
my @newmarks;
@newmarks = sort(@{$marks});
open OFH, ">$marks_file" or die "$!\n";
binmode OFH;
print OFH (join"\n",@newmarks) ."\n";
close OFH;
}
sub read_index_file{
my $index_file = shift;
open FH,"$index_file" or die "Can not open File: $!\n";
my $buffer;
my $bytesread = sysread (FH, $buffer, 10000000);
my $offset = 0;
my $I_counter = 0;
while ($offset < $bytesread) {
my ($c, $Ptype, $number, $reserved) = unpack ("I C C S", substr($buffer, $offset, 8));
#print "Got $c, $Ptype, $number, $reserved\n";
$offset += 8;
#print "offset is $offset\n";
$I_counter++;
$Iframes{$I_counter} = "$c : $number" if ($Ptype == 1);
#push @{$Iframe_list},$I_counter if ($Ptype == 1);
}
print("Got " . (scalar(keys(%Iframes))) . " I-Frames in this index file...\n") if $debug;
# $total_frames = $I_counter;
return ;
};
sub frames2mark {
my $frame = shift;
my $rest = $frame % 25;
my $full_secs = int ($frame * 0.04);
my $h = int($full_secs/3600);
my $min = int(($full_secs - (3600 * $h)) / 60);
my $sec = $full_secs - (3600 * $h + 60 * $min);
return sprintf "%1u:%02u:%02u.%02u", $h, $min, $sec, $rest;
};
sub mark2frames{
my $mark = shift;
my($h, $m, $s, $f) = split /[:.]/, $mark;
my $frame = (3600 * $h + 60 * $m + $s) * 25 + $f ;
return $frame;
};
sub usage {
die 'fixmarks.pl -r /video/recording/...rec';
};
sub parse_options {
my @params = @_;
while ($params[0]) {
my $parm = shift @params;
if ($parm eq "-r") {
if (! $params[0]) {
die "You must supply a recording to the -r option!\n";
}
$recording = shift @params;
} elsif ($parm eq "-d") {
$debug = 1;
}
else {
print "Unknown Option: $parm\n";
usage();
}
}
}
parse_options(@ARGV);
read_index_file($recording . "/index.vdr");
read_marks_file($recording . "/marks.vdr");
save_marks_file($recording . "/marks.vdr");
Alles anzeigen
Ja, ist in der Tat nicht einfach alle Versender zu kennen oder deren Bedingungen. Und dann kommt dazu, das der eine das nicht hat und andere jenes. Im o.a. Beispiel von "anbr" war es mir nicht möglich in dem Shop passende Buchsenleisten im Rastermaß 2.0 zu finden.
Sorry, kann so nicht nachvollziehen
http://www.segor.de/#Q=AWP%252026-2%252C0
Andreas
Ja genau da liegt das Problem, alles andere bekomme ich problemlos, nur das Flachbandkabel im 1mm Rastermaß ist scheinbar nicht für normalos wie mich erhältlich.
Nur als Hinweis zum Flachbandkabel im RM1.0 gibt es z.B. bei Segor : http://www.segor.de/#Q=FB%252044-1%252C0
MfG Andreas
Soeben ist die DD Cine CT V6 bei mir eingetroffen. Beide Tuner sollen im reinen DVB-C-Modus gefahren werden. Bei SAT ist mir klar, dass hier üblicherweise jeder Tuner sein eigenes Kabel benötigt. Muss bei DVB-C und dieser Karte jeder Tuner mit einem Signal bestückt werden? Bei Kabel gibt's ja kein High/Low und horizontal/vertikal, so dass ein Verteiler durchaus schon auf der Karte integriert sein kann... Ein einfaches Ja/Nein reicht ;).
BJ1
Nein, nur der obere Antenneneingang muss angeschlossen werden, der unter Anschluß stellt eine "loop-through" Antennenausgang dar, über den weitere Karten versorgt werden könnten.
Hi,
ich kann nur eine für mich funktionierende Methode beschreiben :
Edith sagt : Falls kein eigener Webspace vorhanden ist, kann auch der Service von Stephan Mestrona genutzt werden : http://stephan.mestrona.net/wol/forum/viewtopic.php?t=923
Es gibt aber viele Weg das Thema anzugehen,
Andreas
ZitatAlles anzeigenFrisch aus der ML
VDR developer version 1.7.29 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.29.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.28-1.7.29.diff
MD5 checksums:
a3f0ae42ba456aa1865c9ed065a64d80 vdr-1.7.29.tar.bz2
39db6b495210c293726126fbcba3e631 vdr-1.7.28-1.7.29.diff
WARNING:
========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The default skin "LCARS" displays the signal strengths and qualities of all devices in its main menu. For devices that have an stb0899 frontend chip (like the TT-budget S2-3200) retrieving this information from the driver is rather slow, which results in a sluggish response to user input in the main menu. To speed this up you may want to apply the patches from
ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches
to the LinuxDVB driver source.
The changes since version 1.7.28:
- Added a missing template specification to the c'tor of cSortedTimers (thanks to Udo Richter).
- Fixed the background color of the Transfer Mode indicator bitmap in the LCARS skin.
- The LCARS skin now only displays devices that can actually receive channels, leaving out, for instance, pure replay devices (suggested by Reinhard Nissl).
- Now scaling down the Transfer Mode indicator bitmap in the LCARS skin in case it doesn't fit with the selected font size (reported by Reinhard Nissl).
- Fixed making LCARS the default skin.
- Adjusted the default values for OSD and font sizes to better fit HDTV.
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Fixed the call to ChannelString() in cSkinLCARSDisplayChannel::SetChannel() (thanks to Rolf Ahrenberg).
- Removed DeleteEvent() from the EPG handler interface (turned out not to be useful) and replaced it with HandledExternally() (thanks to Jörg Wendel).
- Added SetComponents() to the EPG handler interface (thanks to Dirk Heiser).
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Changed the button colors in the LCARS skin to better fit with the rest of the theme.
- Removed the gap from the main menu buttons in the LCARS skin.
- Fixed some copy&paste errors in PLUGINS.html (thanks to Winfried Köhler).
- The LCARS skin's main menu now only displays timers that are actually activated.
- Within the "Recordings" menu, pressing the '0' key now toggles sorting between "by time" and "by name". The selected sort mode is stored separately for each folder (provided you have write access to that folder). If a folder is newly created by a repeating timer, the sort mode for that folder is initially set to "by time".
- Fixed several spelling errors (thanks to Ville Skyttä).
- Fixed handling recording with more than two bonded devices.
- Fixed the type of MBperMinute in cVideoDiskUsage::HasChanged() (thanks to Andreas Mair).
- Setting the "broken link" or "TEI" flags when cutting recordings is now suppressed if the editing point merges two seamlessly fitting parts of the same stream (thanks to Torsten Lang).
- Fixed displaying messages in the LCARS skin.
- Fixed checking for a visible live programme in case a menu or the channel display is currently open.
- Changed some of the colors in the LCARS skin (you may need to delete the file lcars-default.theme from your themes directory to see these changes).
- The new setup option "Miscellaneous/Show channel names with source" can be used to turn on adding the source character to channel names whenever they are displayed (suggested by Ludi Kaleni).
Have fun!
Klaus
Hi,
versuche mal die Version 1.0.0
Andreas
Hi,
Ihr könntet eine aktueller Version von g++ verwenden, z.B. g++-4.6.
oder einen git pull request ausführen.
Andreas
Das kannst per ldd überprüfen
#> ldd /usr/local/bin/lcd4linux
libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0x40006000)
libmpdclient.so.2 => /usr/lib/libmpdclient.so.2 (0x40019000)
libm.so.6 => /lib/libm.so.6 (0x4002f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400d7000)
libc.so.6 => /lib/libc.so.6 (0x400f7000)
librt.so.1 => /lib/librt.so.1 (0x40228000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40237000)
/lib/ld-linux.so.3 (0x2a000000)
=> apt-get install libmpdclient2
Du solltest dir die aktuelle Dev-Version aus dem Subversion Repository ziehen
Siehe auch http://ssl.bulix.org/projects/lcd4linux/wiki/Download ab Subversion Repository
bzw. http://ssl.bulix.org/projects/lcd4linux/changeset/1189/trunk?old_path=%2F&format=zip
Seit http://ssl.bulix.org/projects/lcd4linux/changeset/1149 sollte sich das MPD-Plugin mit aktueller Software übersetzen lassen.
In Richtung Pearl-dpf kann nicht weiterhelfen, das ich des Display nicht verwende.
Wurde das Kernelmodul den sauber geladen, sprich die Ausgabe von dmesg bei modprode ddbridge => Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 1)
Wichtig ist auch per dvb-fe-tool die Empfangsart DVB-T zu aktivieren. (http://www.linuxtv.org/wiki/index.php/DVBv5_Tools)
Hi,
das Thema Module I2C-Core kannst Du ignorieren.
Unter Debian ist es als Modul konfiguriert
$ cat /boot/config-3.2.0-2-686-pae | grep CONFIG_I2C
CONFIG_I2C=m
Unter Ubuntu ist fest in den Kernel eingebaut.
$ cat /boot/config-3.2.0-25-generic | grep CONFIG_I2C
CONFIG_I2C=y