Stalker Portal Manager

[60plus]

Hi,
wenn du nach dem erstellen der m3u, erst die Proxy einstellungen gesetzt hast dann die m3u nochmal erstellen.

 

[tem_invictus]

[3.7.3] - 2026-04-18​

Changed

• Version bumped to v3.7.3.
• M3U playlist creation now requires Proxy Link Base to be configured across portal generation and M3U Editor save flows.
• Settings now warn before changing Proxy Link Base when successful playlists already exist, so users know regeneration is required.

Improved

• Jobs log live updates are now much lighter for large jobs:
• opening a job log stream no longer sends the full historical log snapshot
• live append events update the visible page directly instead of refetching the full paginated log query each time

 

[kusselin]

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

 

[tem_invictus]

[3.8.0] - 2026-04-23​

Changed

• Version bumped to v3.8.0.
• 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.

 

[stefanus85]

hätte gleich einen bug

Spoiler: text

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.

 

[tem_invictus]

[3.8.1] - 2026-04-24​

Changed

• Version bumped to v3.8.1.
• 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.

 

[stefanus85]

rückmeldung: fix war erfolgreich immernoch klasse arbeit

 

[tem_invictus]

[3.8.2] - 2026-04-24​

Changed

• Version bumped to v3.8.2.
• 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.

 

[stefanus85]

Spoiler: doch noch bug?

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?

vielen dank für deine hilfe

 

[tem_invictus]

sprich, wenn du aus der "Portal preset" Liste "c/portal.php" auswählst oder wie?

 

[stefanus85]

ist egal welches preset außer "auto" aber da landet er dann bei files die ich weiß das die nicht gehen wie bsp. "server/load.php"

hab weiter probiert, es scheint daran gelegen zu haben dass ich unter "Advanced tuning" den hacken bei "reset Checkpoint" nicht gemacht hab.

Edit:
Frage zum Scanner selbst, bis 150 macht er die steps "einzeln" zählt also hoch ab 150 gehts dann in 25er schritten ist das so gewollt?

Edit2:
wenn ich ein portal hab was sowieso nur mit /c anzusteuern ist, und auch so hinterlegt ist "

Sie müssen registriert sein, um Links zu sehen

" muss ich dann trotzdem den "portal preset" auf /c/portal stellen oder reicht in dem fall "/portal.php" steuer ja schon via "/c" an?

 

[Schille81]

Wieso nimmst du nicht den auto modus ???

 

[stefanus85]

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 ;-)

Spoiler: Bild_1

Sie müssen registriert sein, um angehängte Bilder zu sehen

 

[tem_invictus]

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.

 

[stefanus85]

ok vielen dank für die erklärung!

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