cinfo
ich habe schon einige von den AMD Mini PCs getestet.
Bisher konnte keiner S3.
Die Händler antworten meist nicht auf die Frage.
unter Windows kann man in der cmd verfügbare Modi auflisten mit: powercfg /a
Posts by onur
-
-
hallo, ich hätte eine frage zu AMD mini PC und S3-Standby.
Ich brauche zwingend S3 Standby (Modern Standby ist nicht zu gebrauchen).
Am liebsten ist mir ein AMD System, da es weniger Probleme mit HDMI Ton gibt.
AMD hat quasi eingebautes EDID - wenn man kabel absteckt - bleibt die Auflösung.
Ich finde kein AMD System das Standby S3 kann (ging nur bis zur 3er Serie).
Die dinger haben alle einen Soc - Chipsatz: System-on-Chip (SoC).
SoC bedeutet das die CPU die Chipsatzfunktion übernimmt - und die neuen AMD Cpus können kein S3.
weiß jemand mehr?
danke, gruss, onur -
Ich versuch mal eine Schnellanleitung - im Anhang sind meine Konfig Dateien.
unter Linux muss mono installiert werden - Anleitung siehe Webpage
http://webgrabplus.com/download
5€ spenden - dann bekommt man Kennwort (dauert ca. 1 Stunde), oder man verwendet die eingeschränkte Version.
Datei WebGrab++.config.xml
haupt-Konfig Datei (hier kommt username/pass rein, und die gewünschten Sender)
<timespan>20</timespan> (anzahl tage, achtung 0 bedeutet 1 Tag!)
<postprocess grab="y" run="n">mdb</postprocess> mit run="y" würde er einen IMDB Abgleich machen - dauert aber lange.
Ergebnis mdb_guide.xml liegt dann im unterordner mdb
das normale grab ergebnis liegt im hauptordner guide.xml.
Info: Ausgabe Dateinamen sind Variabel bzw. einstellbar.
Datei vdr.tvdigital.de.channels.xml
dies ist die liste der channels - die man grabben kann
hier muss nicht angepasst werden.
Datei vdr.tvdigital.de.ini
hier wird festgelegt wie die Webseite gegrabt werden soll. hier muss nichts angepasst werden.
Datei Documentation.V3.0.pdf
hier steht auch drin wie man die site.ini selber anpassen kann (falls sich auf der Webseite was ändert - oder man frag den support).
andere Webseiten findet man im Ordner siteini.pack
Ich habe keine andere Web TV-Zeitschrift gefunden die star-rating, episode-num und Tipp kann.
ich habe tvdigital.de.ini per support anpassen lassen damit star-rating und TVTipp funktioniert, allerdings ist die xml ausgabe für tipp und star-rating eher nicht standardkonform.
Programm starten und warten (ca. 2 Minuten pro Sender/14 Tage)
falls es Probleme gibt, sieht man dies in der log Ausgabe (der support reagiert schnell, wenn man 5€ zusätzlich spendet).
hier noch 2 Screenshots vom Ergebnis.
-
ich habe nun WebGrab+Plus mit tvdigital.de im Einsatz (5€ spende notwendig).
funktioniert super - ist aber relativ aufwendig zu konfigurieren.
der support ist auch super und hilft einem schnell (xml Ausgabe Anpassung, zusätzliche tags berücksichtigen) usw...das grabben für 100 sender, 14 tage dauert 3 stunden.
-
ich habe mal https://zhort.de/epg14 getestet.
14 tage version: von hier: https://free-epg.de/epg-service/
bin aber nicht ganz glücklich.
hat jemand WebGrab+Plus hier im einsatz und erfahrung.
-
hat den niemand eine quelle?
kann man nur selber grabben? -
Hi,
epgData.com wird(wurde) eingestellt.
kennt jemand eine zuverlässige quelle für fertige xmltv Daten.
ich bin auch bereit dafür zu zahlen.
danke, gruß, onur -
-
für alle jene die eine specherleck suchen, und die valgrind ausgabe etwas verringern wollen, die müssen den vdr mit so einem sleep bauen.
aber auch 200ms ist nicht verlässlich, leider ist das ganze stark cpu (anzahl und auslastung) abhängig.
echt frustrierend.
zumindest liefert valgrind (auch ohne patches) nach dem beenden das richtige ergebnis.
die ausgabe zur laufzeit ist falsch.
LEAK SUMMARY:==29891== definitely lost: 0 bytes in 0 blocks
==29891== indirectly lost: 0 bytes in 0 blocks
==29891== possibly lost: 0 bytes in 0 blocks
-
ich habe alle varianten durchgetestet - damit es schnell geht - mit einem TestThread.
verlässlich ist keine der varianten - alles ziemlich sinnlos.
am verlässlichsten funktioniert valgrind, wenn man in cThread::StartThread vor dem Aufruf von Action, ein sleep mit 200ms macht.
dann meckert valgrind nicht mehr.
-
pthread_attr_destroy kann man direkt nach thread create machen.
if (attrp) pthread_attr_destroy(attrp);
Solution 3 - signalisert valgrind das der thread detached läuft.
ansonsten weiß das valgrind ja nicht sofort (valgrind meckert wenn zwischen pthread_create und pthread_detach ein malloc/new gemacht wird).ich habe das ganze so verstanden:
pthread_detach bewirkt das nach thread ende, alle thread ressourcen freigegeben werden.
vereinfachtes Beispiel:
pthread_create = erstellt ein globales handle mit nummer 1 (unser childTid).
wenn der thread beendet wird exisitert dieses handle weiter, damit childTid vom aufrufenden thread weiter gültig bleibt.
pthread_detach (egal woher es aufgerufen wird) bewirkt:
alle thread ressourcen (childTid) bitte nach thread ende freigeben.
die variable childTid ist ab diesem zeitpunkt unsicher.
es könnte sogar passieren das inzwischen ein anderes pthread_create die selbe id vergeben hat.
im vdr code wird das durch die variable Thread->threadrunning = false geprüft.
hier könnte man zusätzlich ein Thread->childTid=0 machen (falls man pthread_detach in den thread verschiebt - Solution 2).
-
keine ahnung ob man hier von einem problem sprechen kann.
eventuell sollte man über Solution 3 nachdenken:
https://stackify.dev/907998-valgrin…-pthread-create
meine lösung ähnelt Solution 2. -
@mini73
ich habe folgendes beobachtet:
valgrind bemerkt dass ein thread gestartet wird, und regsitriert malloc/new aus diesem thread.
Wenn nun vor thread ende ein pthread_detach gemacht wird, denkt vargrind das der thread speichlecks hat.
Wenn pthread_detach gemacht wird, bevor im thread ein malloc/new gemacht wird (zufall), dann meckert valgrind nicht.
speicher-leck suche ist dadurch schwierig. -
Thread->childTid habe ich korrigiert.
damit childTid auch gültig ist sollte man nach einem erfolgreichem pthread_create() - auf den thread warten.
z.B mit Funktion WaitForThreadStart und Variable bThreadStarted (bThreadStarted muss natürlich im konstruktor mit false initialisert werden)
Code
Display Morevoid *cThread::StartThread(cThread *Thread){ Thread->bThreadStarted = true; .. } Bsp für WaitForThreadStart: void cThread::WaitForThreadStart() { struct timespec req, rem; req.tv_sec = 0; req.tv_nsec = 1000; cTimeMs timeout; timeout.Set(0); while (!bThreadStarted){ uint64_t elapsed = timeout.Elapsed(); if (elapsed > 500) //nach 500ms aufgeben{ esyslog("ERROR: WaitForThreadStart Timeout 500ms %s", description ? description : ""); break; } else{ nanosleep(&req , &rem); } }; }
-
@mini73
wenn im Thread ein malloc gemacht wird,
dann denkt valgrind das dieses malloc nicht mehr freigegeben wird, da ja bereits pthread_detach aufgerufen wurde.zumindest ist das meine beobachtung.
-
@nvertigo
in: cThread::StartThreadpthread_detach(Thread->childTid); // auto-reap
return NULL;
bei mir läuft vdr auch amok wenn ich mit aktivem valgrind tune.
das habe ich mir nicht so genau ansgeschaut. -
Hallo, hätte einen Verbesserungsvorschlag:
ich prüfe mittels valgrind auf Speicherlecks.bei den vdr threads läuft aber etwas schief (ausgabe unschön).
falls innerhalb des threads ein malloc gemacht wird - gibt es einen fehler von valgrind.valgrind denkt wohl das der thread direkt nach dem start zerstört wurde.
wenn man "pthread_detach(childTid)" nach cThread::StartThread(ans ende, vor return true;) verschiebt, dann klappt es besser.
gruß, onur -
hi,
suche libciplusprivate.so, google findet nichts?
-
Ich habe fälschlicherweise angenommen das dies seit 2.3.3 nicht mehr benötigt wird.
Da ORF wohl keine shared ca pids mehr hat, habe ich einen falschen Schluss gezogen. -
hallo, leider gibt es das problem derzeit auf orf nicht (ich habe auch keine kombi gefunden).
eventuell aber von 19:00-19:15, da laufen die regional Programme (teste ich heute).
SRF kann ich derzeit auch nicht empfangen/entschlüsseln.
ich habe immer mit diesen 2 Kanälen getestet.ORF2V HD;ORF:11273:HC23M5O35P0S1:S19.2E:22000:3000:0;3001=deu,3002=mis:3005:D98,650,D95,648,6E2,98C,9C4,500:13307:1:1005:0
ORF SPORT+ HD;ORF:11273:HC23M5O35P0S1:S19.2E:22000:3090:0;3091=deu,3092=mis:3095:D98,650,D95,648,6E2,98C,9C4,500:13309:1:1005:0