Kann das bitte nochmal jemand hier erklären wie das mit dem EPG funktioniert im Portalmanager… ich bekomms nicht hin..
Wenn ich zb die m3u in tivimate reinkopiere dann werde ich ja im letzten Schritt nach der EPG Quelle gefragt…kann ich da irgendeine eingeben? Habt ihr einen Favorit?
Über ne Info herzlichen Dank. Sonst läuft alles..danke nochmals @tem_invictus
The app now includes an integrated Portal Scanner workflow for creating runs, launching background scans or endpoint checks, reviewing results, and importing selected hits.
Added
A bundled feature-scanner Python scanner with workspace docs, helper tooling, and automated tests.
ANMERKUNG!
Zu den Scanner Funktionen gibt es keinen Support von mir. Solltet ihr Bugs feststellen könnt ihr die gerne melden.
Sie müssen registriert sein, um angehängte Bilder zu sehen
Folgende Meldung wenn ich einen Scan abbrechen möchte: Scan läuft lt. Tabelle unter Scanner / im Jobs Tab ist kein run vorhanden / wenn ich den Job abbrechen möchte kommt folgende meldung. - Scan geht auch lt. Statistik weiter.
edit1: die jobs dazu sind nicht mehr vorhanden. löschen unter /var... scanner/runs.. bringt auch nichts. wenn ich eine db restoren möchte: Incompatible backup schema: 0032_hot_query_indexes. Expected 0033_scanner_runs.
Anhänge
Sie müssen registriert sein, um die Liste der Anhänge zu sehen
The main operational pages now use the newer route shell and status-strip layout across Portals, Portal Detail, Portal Edit, Scanner, M3U Editor, Jobs, Proxy Logs, Notifications, Diagnostics, Schedules, and Settings.
Jobs and Proxy Logs cleanup actions are now collapsed by default, and the Scanner page keeps run setup, selected run, and results sections collapsed until opened.
Fixed
Startup stuck-job recovery now ignores active scanner jobs so long-running scans and endpoint checks are not failed as generic stuck work.
Stopping an active scanner run now cleanly marks orphaned or missing-job runs as cancelled instead of failing when the backing job record is gone.
Job log lines are no longer mirrored to Docker stdout by default, which keeps container logs much quieter during large background jobs.
Stuck-job recovery now uses recent job-log activity as the heartbeat for long-running jobs, so large MAC checks are not retried solely because total runtime exceeds the worker timeout.
Frontend routes now lazy-load by page, reducing the initial JavaScript bundle size.
Improved
Expired and inactive MAC cleanup now fetches only matching IDs, deletes dependencies in chunks, and uses new cleanup-focused indexes.
Portal Detail now memoizes several large derived lists and counters to reduce repeated work during routine UI updates.
ok ergänzend muss ich fragen, gibt es noch eine möglichkeit seine jobs zu kontrollieren?
grund ist das problem mit dem job stop oder auch mit dem löschen der jobs geht wieder.
aber irgendwie aus einem grund auch immer beim scan auf ein portal, bei dem ich noch angeben muss dass er direkt auf /c/portal gehen soll muniert er immer das dieser job schon existiert aber laut dem ersichtlichen ist das nicht so.
deshalb die frage muss ich in der app.db nachschauen?
Error: PID: 64 = ist das ne zeile die ich "einfach" so löschen könnte?
weil der scanner dann wie oben beschrieben auf files losgeht die nicht scanbar sind, siehe dazu bild 1. Genau auf die geht er dann los /portal.php, /server/load.php ich brauche ihn aber nur auf c/portal.php. das ist genau der grund meiner frage ;-)
Sie müssen registriert sein, um angehängte Bilder zu sehen
Anhänge
Sie müssen registriert sein, um die Liste der Anhänge zu sehen
das hoch zählen der schritte ist einfach nur die anzeige. eigentlich könnte man auch ab Anfang an in 25er schritte anzeigen lassen.
geht nur drum, die performance zu verbessern. der scanner arbeitet im Hintergrund natürlich eine nach dem anderen ab.
zum mit oder ohne /c angeben, wenn /c schon in der portal URL hinterlegt ist. gute frage, probier mal aus und gibt bescheid .
weiß ich tatsächlich nicht, wie der scanner da reagiert.
im auto modus, sollte der scanner zum start einmal alle endpoints abklappern und danach versucht er logischerweise nur bei denen, die auch erreichbar sind.
rückmeldung:
sobald die portal url am ende mit "/c" (bsp:
Sie müssen registriert sein, um Links zu sehen
) endet, muss man nicht mehr auf /c/portal.php scannen, portal.php reicht dann, sieht er es als /c/portal.php an. konnte man sehr gut über die log json's rausfinden (event)
was aber komisch ist mit "MAC-List" hab ich 6 macs welche im portal 100% haben durchgejagt allerdings alle als error markiert. ja das portal spuckt "512" fehler ist zwar cloudflare kann man aber ignorieren laut meiner erfahrung. 521er von CF sind "echte" fehler. zumindest war das so als man kaboom beim scannen zusah
wenn ich die option falsch genutzt hab bitte ich um kurze aufklärung
edit:
egal ob "Cloudscraper" aktiv war oder nicht, keine veränderung der testergebnisse