Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Kein Problem... Bei mir funktioniert jetzt auch die manuelle Suche nicht mehr - egal, wonach ich suche, ich bekomme nur noch die Meldung, dass kein Ergebnis gefunden wurde. In der cddb_resul_file.temp wird zwar angebene, dass etwas gefunden worden sei, aber es flackern nur unlesbar schnelle irgendwelche Meldungen durch, es wird aber kein Suchergebnis angezeigt. Hier der entsprechend Ausschnitt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | <input type="submit" value="Search">
</form>
<h2>Search Results, 29 albums found:</h2>
<br><br>
<br>
</div>
<div id="footer">
<center>Copyright © 2021, GnuDB and all the Contributors</center>
<br><br><br><br>
<center>
Hosting made possible with help from <a href="https://www.kodyl.com/" target="_blank">Kodyl</a> and <a href="https://www.evergreen-internet.dk/" target="_blank">Evergreen Internet.</a>
</center>
</div>
</div>
<br>
|
Aber es scheint aucu Probleme mit dem Paket libcddb2 zu geben - versuche das gerade zu erkunden. so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Ich kam jetzt dazu das zu testen. Unter abcde funktionierte die cddb-Abfrage problemlos, ich hatte aber natürlich alles ohne tags gerippt, da ich ja EasyTag testen wollte. Probleme hatte ich mit musicbrainz, welches ich nach den o.g. Settings hinzugefügt habe. Zunächst konnte der Name angeblich nicht aufgelöst werden, was drill und resolvectl aber nicht bestätigen konnten (dort war es bereits durch die EasyTag-Anfrage gecacht), ein erneuter Versuch brachte nach 238kb Daten ein connection timeout. Was das zugrunde liegende Problem dabei ist, weiß ich allerdings nicht, die Logfiles sind leer. Nach Entfernen von musicbrainz zu meinem vorherigen Setup, funktionierte die Anfrage auf Anhieb; es gibt aber bei der reinen Verwendung von des cddbd auf Port 8880 innerhalb EasyTags Probleme, leider auch hier ohne geloggte Infos. Die einzelne Liedsuche gab zudem falsche Ergebnisse. Da scheint wirklich etwas bei EasyTag oder den hinterlegten Bibliotheken nicht zu stimmen, da abcde als „schnödes Bash-Script“ die richtigen Ergebnisse liefert. Was die genaue Problematik angeht, weiß ich nun auch nicht mehr zu berichten. Das einzige, was mir noch im Hinterkopf hängt ist, dass in abcde ein Workaround drin ist, um die bei anderen Programmen zu lang berechneten CD-Schlüssel kompatibel zu halten, das dürfte aber mittlerweile verjährt sein. Möglicherweise gibt es bereits einen Bug-Bericht dazu, ich konnte aber keinen passenden finden (was auch daran liegt, dass ich das Problem nicht eingrenzen kann). Die Suche mittels freedb.freac.org liefert die selben falschen Ergebnisse wie die Suche auf gnudb.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! ChickenLipsRfun2eat schrieb:
Nach Entfernen von musicbrainz zu meinem vorherigen Setup, funktionierte die Anfrage auf Anhieb; es gibt aber bei der reinen Verwendung von des cddbd auf Port 8880 innerhalb EasyTags Probleme, leider auch hier ohne geloggte Infos.
Zwei Fragen:
Die eigentliche Suche nach Alben funktoniert bei mir auch, allerdings kann ich dann die gefundenen Alben nicht aufrufen und zum Taggen verwenden. Geht das bei dir? Wie verwendest du cddbd auf Port 8880 in easyTAG? Muss der Dienst dafür extra gestartet werden, und, wenn ja, wie?
Dass für einzene Songs "falsche" Daten gefunden wurden, wundert mich dagegen wenig, da dafür nicht genügend Anhaltspunkte überliefert werden können, also z.B. kein "Fingerprint" wie bei musicbrainz. Das hatte ich auch mit ganzen Veröffentlichungen, die nur 2-3 Titel hatten; da wird dann auch mal ein Album ausgegenen, dessen Titel zufällig die gleichen Titellängen in der richtigen Reihenfolge haben. Ich habe mi das Programm auch aus dem Sourcecode gebaut - und da gibt es dann, sobald ich versuche, aus den gefundnen Ergebnissen eines aufzurufen, einen Crash mit Speicherzugriffsfehler 🐸 Aber trotzdem Danke für deine Mühe 👍 . Da ist es wohl an der Zeit einen Bugreport zu schreiben, oder zumindest den bestehenden noch mal aufzugreifen so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Zwei Fragen:
Ja, das Übernehmen der falschen Tags funktioniert. Wie verwendest du cddbd auf Port 8880 in easyTAG? Muss der Dienst dafür extra gestartet werden, und, wenn ja, wie?
Das verwendet man nicht „manuell“, sondern hängt von der Implementierung ab. In EasyTag bedeutet das, dass du lediglich den Port auf 8880 ändern musst, um das zu nutzen — was aber da nicht funktioniert. Bei abcde kannst du das in der Konfigurationsdatei einstellen: CDDBMETHOD=cddb
CDDBURL="http://gnudb.gnudb.org/~cddb/cddb.cgi"
CDDBSUBMIT=submit@gnudb.org
CDDBLOCALDIR="$HOME/.cache/cddb" Dass für einzene Songs "falsche" Daten gefunden wurden, wundert mich dagegen wenig, da dafür nicht genügend Anhaltspunkte überliefert werden können, also z.B. kein "Fingerprint" wie bei musicbrainz. Das hatte ich auch mit ganzen Veröffentlichungen, die nur 2-3 Titel hatten; da wird dann auch mal ein Album ausgegenen, dessen Titel zufällig die gleichen Titellängen in der richtigen Reihenfolge haben.
Ja, ich hatte da zum Test einzelne Tracks ausgewählt. An sich sollte trotzdem keine falsche Liste kommen, zumindest nicht bei Daten von einer CD. Dafür wird ja extra aus dem CD-Header ein Schlüssel generiert, der zur Abfrage und Speicherung genutzt wird; dieser ist ja dann auch hinterlegt.
Ich habe mi das Programm auch aus dem Sourcecode gebaut - und da gibt es dann, sobald ich versuche, aus den gefundnen Ergebnissen eines aufzurufen, einen Crash mit Speicherzugriffsfehler 🐸
Hast du ne backtrace dazu? Ansonsten kompiliere mal mit der Option -g (bei g++) und starte es danach mit gdb ~/kompilat/easytag . Da kannst du nach dem Crash dann bt eingeben.
Aber trotzdem Danke für deine Mühe 👍 . Da ist es wohl an der Zeit einen Bugreport zu schreiben, oder zumindest den bestehenden noch mal aufzugreifen
Ja, gerne. Ich kann das gerne noch mal mit anderen, bekannteren CDs testen; die sind nur im Keller eingelagert, um sie „irgendwann“ mal weiterzurippen 😉 Kannst du den Bugreport mal verlinken?
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Wo muss ich beim Kompilieren die Option -g angeben? ./configure will das nicht haben, make auch nicht... so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Wo muss ich beim Kompilieren die Option -g angeben? ./configure will das nicht haben, make auch nicht...
Bevor du make ausführst, kannst du theoretisch die flags anpassen oder den compiler. Beispielsweise mit export CC=/usr/bin/gcc -g . $CC ist die Variable, die make normalerweise benutzt. Alternativ kannst du das auch über die CFLAGS machen oder direkt im (generierten) Makefile rumwurschteln. Falls ET cmake oder ähnliches nutzt, dann ist es wieder ein wenig anders, daher erstmal etwas allgemeiner.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Hat soweit geklappt; für das selbstgebaute easytag, nach dem Versuch, eine gefundenes Album aufzurufen, erscheint im Terminal Folgendes 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83 | (gdb) run
Starting program: /home/heinrich/Downloads/Software/64-bit/easytag-master/easytag
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff35a0700 (LWP 111109)]
[New Thread 0x7ffff2d9f700 (LWP 111110)]
[New Thread 0x7ffff1b45700 (LWP 111111)]
[New Thread 0x7fffe3fff700 (LWP 111112)]
[New Thread 0x7fffe37fe700 (LWP 111113)]
[New Thread 0x7fffe2ffd700 (LWP 111114)]
[New Thread 0x7fffe27fc700 (LWP 111115)]
[New Thread 0x7fffe1d4a700 (LWP 111116)]
[Thread 0x7fffe2ffd700 (LWP 111114) exited]
[Thread 0x7fffe37fe700 (LWP 111113) exited]
[Thread 0x7fffe3fff700 (LWP 111112) exited]
[Thread 0x7fffe27fc700 (LWP 111115) exited]
[New Thread 0x7fffe27fc700 (LWP 111118)]
[Thread 0x7fffe27fc700 (LWP 111118) exited]
[New Thread 0x7fffe27fc700 (LWP 111132)]
Thread 1 "easytag" received signal SIGSEGV, Segmentation fault.
0x0000555555583e8f in log_message_from_request_error (message=0x555556302ab0,
error=<optimized out>) at src/cddb_dialog.c:712
--Type <RET> for more, q to quit, c to continue without paging--
712 uri = soup_message_get_uri (message);
(gdb) bt
#0 0x0000555555583e8f in log_message_from_request_error
(message=0x555556302ab0, error=<optimized out>) at src/cddb_dialog.c:712
#1 0x00005555555840bc in Cddb_Get_Album_Tracks_List
(selection=<optimized out>, self=0x555555c9f8d0) at src/cddb_dialog.c:819
#2 Cddb_Get_Album_Tracks_List_CB
(self=0x555555c9f8d0, selection=<optimized out>) at src/cddb_dialog.c:1061
#3 0x00007ffff7136802 in g_closure_invoke ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007ffff714a814 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x00007ffff7155bbe in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007ffff71560f3 in g_signal_emit ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007ffff7acbbf6 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#8 0x00007ffff7ad2f58 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#9 0x00007ffff7b3eae1 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x00007ffff7136a56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff7155b48 in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007ffff71560f3 in g_signal_emit ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff7956368 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x00007ffff7139c56 in g_cclosure_marshal_VOID__BOXEDv ()
--Type <RET> for more, q to quit, c to continue without paging--
x-gnu/libgobject-2.0.so.0
#15 0x00007ffff7136a56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff7155b48 in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff71560f3 in g_signal_emit ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff795304e in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#19 0x00007ffff79545fb in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x00007ffff7957646 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x00007ffff791ebb0 in gtk_event_controller_handle_event ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#22 0x00007ffff7ae116d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#23 0x00007ffff7b385ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#24 0x00007ffff7136a56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x00007ffff7154df1 in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff71560f3 in g_signal_emit ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x00007ffff7ae2c23 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x00007ffff799e128 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#29 0x00007ffff79a03db in gtk_main_do_event ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#30 0x00007ffff7688f79 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#31 0x00007ffff76bc106 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#32 0x00007ffff704917d in g_main_context_dispatch ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#33 0x00007ffff7049400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#34 0x00007ffff70494a3 in g_main_context_iteration ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#35 0x00007ffff7264fe5 in g_application_run ()
at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#36 0x0000555555573d57 in main (argc=1, argv=0x7fffffffe588) at src/main.c:38
(gdb)
|
Für mich sieht es so aus als ob
error=<optimized out>) at src/cddb_dialog.c:712
Auslöser für den crash ist, was immer es beudeuten mag 😉 so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Richtig. Ich mutmaße jetzt einfach mal, dass die Nachricht zu groß ist und gerade da blöderweise in den nicht mehr zugreifbaren Speicherbereich geschrieben wird oder an der Stelle der Pointer schon gelöscht wurde. müsste man sich in der cddb_dialog.c angucken.
|
Heinrich_Schwietering
Wikiteam
(Themenstarter)
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi!
Der Teil des codes soeht so aus:
static gchar *
log_message_from_request_error (SoupMessage *message,
GError *error)
{
SoupURI *uri;
gchar *msg;
uri = soup_message_get_uri (message);
switch (message->status_code)
{
case SOUP_STATUS_CANT_RESOLVE:
case SOUP_STATUS_CANT_RESOLVE_PROXY:
msg = g_strdup_printf (_("Cannot resolve host: ‘%s’: %s"),
soup_uri_get_host (uri), error->message);
break;
case SOUP_STATUS_CANT_CONNECT:
case SOUP_STATUS_CANT_CONNECT_PROXY:
case SOUP_STATUS_TOO_MANY_REDIRECTS:
default:
msg = g_strdup_printf (_("Cannot connect to host: ‘%s’: %s"),
soup_uri_get_host (uri), error->message);
}
return msg;
}
Die markierte Zeile ist die monierte 712; scheint mir so, als ob der Dialog, der den Fehler anzeigen soll, nicht angezeigt werden kann; der Aufruf der Dateiliste also schon gescheitert ist, jetzt aber keine Fehlermeldung mehr erfolgt sondern das Programm crasht, weil damit irgendwas nicht in Ordnung ist. so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ja, das müsste man weiter zurückverfolgen. Also zum einen die SoupMessage *message, in dessen Initialisierung (und/oder Definition der SoupMessage für ein eventuelles Maximum) sollte die Größe des Speicherbereichs zu ermitteln sein, die zugeordnet wurde und dann natürlich die soup_message_get_uri-Methode, die da reinschreibt. Das dann noch für SoupURI und den Rückgabewert der Methode, da innerhalb der Methode ein Speicherbereich definiert werden muss, der dann zurückgegeben wird und den Pointer auf uri valide macht. Könnte natürlich auch sein, dass man da noch tiefer gegen muss, wenn bspw. mit GTK-Mitteln gearbeitet wird. Diese sind ja woanders definiert. Müsste mir das mal ansehen, allerdings ohne Garantie, ich bin auch nur Hobby-Programmierer auf Anfängerniveau (und darüber komme ich auch nicht hinaus 😉 )
|