Forum

ja das wollte ich wissen damit ich dann ggf. was gegen tun kann.

in dem Fall

>oder OPN2 selbst umbauen damit Selbiges z.b. nur
>30 Einträge cachet und es somit nicht so diesem Fehler kommt

edit:

mit

trunk rev. 1620
branch rev. 1621

korrigiert

aaaaalssooo ;D

Mein Kollege hat Nachts 440 Downloads eingetragen, diese aber nicht aktiviert. Egal was ich tat, ich kam nirgendwo mehr rein (siehe Fehlermeldung)

Also ging ich per SQLdumper auf die DB drauf sicherte den Table
opn_downloads_newlink in einen dump. Den dump speicherte ich auf meiner Platte und löschte daraufhin den Inhalt des Tables direkt in der Datenbank (waren ja entschieden zuviele Einträge)
Lokal öffnete ich den SQL Dump File und extrahierte die dortigen Downloadeinträge in einen jeweils seperaten SQL Dump. (ca 60 - 80 einträge pro File)

Diese lud ich wieder alle auf meinen host und haute Selbige nacheinander wieder in den opn_downloads_newlink Table.
Immer wenn ein dump drinne war ging ich in den Adminbereich (der erst bei weniger als 20 Einträgen im genanntem Table flüssig lief) und aktivierte dort die Einträge welche ich zuvor in den table einspielte.

War sehr nervig, vor allem wirds OPN2 sehr lahm wenn man mehr als ca 20 Einträge in der Liste hat, aber ich habs hinbekommen.

Andere Möglichkeit wäre evtl. gewesen die Timeout oder Speicherreservierungssettings auf dem Host zu ändern um somit das timeout zu umgehen oder OPN2 selbst umbauen damit Selbiges z.b. nur
30 Einträge cachet und es somit nicht so diesem Fehler kommt :d

Ich vermute aber ich bin den schnellsten und einfachsten Weg gegangen

So ich hoffe Dich hat das wirklich interessiert :d

Grüße

edit: Ich hätte auch den DUMP aus dem Table opn_downloads_newlink ändern können und den dann direkt nach opn_downloads_links importieren, habe ich auch versucht ging aber nicht da wohl gewisse Felder fehlten.

Öhm dein vorgehen und den zweck hab ich nicht verstanden.

Nein, einfach ganz normale Downloadeinträge.

Eigentlich nur Titel Link und Beschreibung, (Habe das Formular beschnitten *g*) waren eben viele Einträge

Habe den kompletten New_link Table gedumpt und die sql mittem texteditor gesplittet in ca 80 Einträge pro sql file.
Die habe ich dann jeweils eingespielt, die Einträge aktiviert und dann den nächsten.

Ich habe festgestellt das es erst ab weniger als 20 unaktiverten DL Einträgen einigermassen flüssig läuft, alles mehr als 20 ist ein einziger Krampf, nur Timeouts und ewig hohe Ladezeiten.

also

>Fatal error: Allowed memory size of 41943040 bytes exhausted

Sagt ja das du dein Speicherlimit erreicht hast allerdings frage ich mich wie man an der Stelle 40 MB erreichen kann. Gibts da besondere Boxen oder so? Weil 40 MB braucht eigentlich keine Stelle in OPN außer ggf. ISO-Composer

Du sollst doch nicht in OPN mit Feuer spielen.

Sorry, den konnte ich mir bei dem Threadtitel nicht verkneifen.

Hallo !

Habe mal wieder ein Problem.

Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 17163267 bytes) in ...../class/engine/class.opn_output.php on line 1029

Dies kommt bei Aufruf der "downloads freischalten" Seite im Adminbereich oder bei klick auf "Neue Downloads.." auf der Startseite.
Meist kommt aber ein Script oder Servertimeout.

Neue Downloads: 439

Könnte es daran liegen ? Die warten alle noch auf Freischaltung/Aktivierung. Kann man das anpassen (umhacken) im OPN" selbst oder ist das eher ein nichtumgehbares Server-Script-Speicherzuweisungsmaximum ?

Ich möchte nicht 439 oder mehr Files (Kollege meint weit über 800)
manuell in der DB löschen oder Ahnliches..

Grüße