SpotWeb - Webbased Spotnet - deel 2

[albatross]

Heb een groot MariaDB probleem met spotweb! Alles prima geinstalleerd, en handmatig de retrieve.php een uurtje of wat laten draaien. Dat ging ook vlekkeloos. Maar dan begint het! Zodra ik dit voor het eerst laat draaien binnen een Scheduled Task (Windows 10) flipt MariaDB totaal, crasht, en is mijn database zo corrupt geworden dat MariaDB zelfs niet meer op kan starten!

c:\xampp\php\php.exe c:\xampp\htdocs\spotweb\retrieve.php --force

Er is eigenlijk absoluut niets aan dit simpele script dat zo'n geweldige (reproduceerbare) crash kan veroorzaken (zie hier onder). En daarna is de database fubarred beyond recognition! De Scheduled Task draait als 'mij', en is hidden (zodat er geen console wordt geopened, iedere 30 minuten)

2016-06-06 16:39:16 7716 [Note] Server socket created on IP: '::'.
2016-06-06 16:39:16 7716 [Note] C:\xampp\mysql\bin\mysqld.exe: ready for connections.
Version: '10.1.13-MariaDB' socket: '' port: 3306 mariadb.org binary distribution

.... tot hier alle posts toegevoegd via handmatig gedraaid retrieve script ....

En nu begint het Scheduled Script te lopen (precies om 16:47 uur):

InnoDB: Error: trying to access page number 250370 in space 69,
InnoDB: space name spotweb/commentsxover,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
2016-06-06 16:47:38 a74 InnoDB: Assertion failure in thread 2676 in file fil0fil.cc line 5866
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/...cing-innodb-recovery.html
InnoDB: about forcing recovery.
160606 16:47:38 [ERROR] mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware

[mesa57]

Lastig zeg. Voor het eerst dat ik een dergelijk issue zie.
Wat je zou kunnen proberen is de commentsxover tabel te 'droppen' en dan het upgrade-db.php script te draaien. Die maakt hem weer overnieuw aan.
Heb je wel genoeg ruimte voor de database op je schijf ?

[Dannisi]

Waarom --force?
Dan kunnen er meerdere retrieves tegelijk draaien, ik zou denken dat dat dingen kapot kan maken.

[albatross]

mesa57 schreef op maandag 06 juni 2016 @ 19:51:
Lastig zeg. Voor het eerst dat ik een dergelijk issue zie.
Wat je zou kunnen proberen is de commentsxover tabel te 'droppen' en dan het upgrade-db.php script te draaien. Die maakt hem weer overnieuw aan.
Heb je wel genoeg ruimte voor de database op je schijf ?

Het is opgelost! Iemand op de MariaDB mailing list had the tegenwoordigheid van geest om de issue te herkennen:

https://jira.mariadb.org/browse/MDEV-9977

Het was een bug (en een vrij ernstige, moet ik zeggen). Na de upgrade naar 10.1.14 draait alles weer naar behoren!

[albatross]

Dannisi schreef op dinsdag 07 juni 2016 @ 03:32:
Waarom --force?
Dan kunnen er meerdere retrieves tegelijk draaien, ik zou denken dat dat dingen kapot kan maken.

Ik geloof dat het idee achter 'force' ooit was dat je daarmee een 'hangend' proces kunt omzeilen. Maar ik heb die parameter inderdaad toch maar even weggehaald. Ik heb immers de Scheduler lopen, die dat veel beter doet (niet opstarten als de taak al gaande is, en de taak afbreken als ie al meer dan 4 uur loopt).

[Dannisi]

Maar dat process hangt voor een reden. Dat --force maakt meer kapot dan dat het ooit kan oplossen.

[albatross]

Dannisi schreef op dinsdag 07 juni 2016 @ 06:09:
Maar dat process hangt voor een reden. Dat --force maakt meer kapot dan dat het ooit kan oplossen.

Er is een verschil tussen hangen en gewoon nog aan het draaien zijn. Iig kan het minder kwaad dan je denkt. Tegenwoordig is alles netje transaction-safe (vanuit MariaDB). Ook wanneer dat script daadwerkelijk meerdere keren loopt, dan nog gaat er niks echt mis (je update zou wellicht een pietsje langzamer kunnen gaan, met multiple instances, omdat posts meerdere keren (sequentieel nog steeds) weggschreven worden. Dat gaat echt niet over elkaar heen clobberen.

Hoe het ook zij, de --force optie was ooit bedacht, zodat mensen niet een paar dagen later er pas achter kwamen dat hun retrieve.php hing (echt hangen), en er dus dagenlang niet geupdate was op de server.

De 'normale' procedure is om eerste keer retrieve.php handmatig uit te voeren (kan ff duren), en daarna, via een schedule, de zaak periodiek op te laten starten. Als je dat, zeg, iedere 30 minuten of zo laat doen, dan is het al heel stug wanneer de eerstvolgende taak ook daadwerkelijk een halfuur aan het draaien is. En de gedachte was dan, dat, wanneer het onverhoopt nog steeds aan het runnen was, dat het proces effectief 'unresponsive' was geworden.

[Dannisi]

Maar dan is het een stuk netter om een error te geven ('he, er is nog een process bezig, is dat wel de bedoeling?') dan maar nog een process starten, en hopen dat de 2e wel goed gaat.

[mesa57]

De --force optie is bedoelt voor het geval je handmatig retrieve.php afbreekt / cancelled.
De status blijft dan nml. op 'running' staan, en de retrieve wil dan niet meer starten.

[albatross]

mesa57 schreef op dinsdag 07 juni 2016 @ 09:28:
De --force optie is bedoelt voor het geval je handmatig retrieve.php afbreekt / cancelled.
De status blijft dan nml. op 'running' staan, en de retrieve wil dan niet meer starten.

Dat kan 1 van de gevallen zijn waar retrieve.php 'unclean' afgesloten werd (server reset?). Dan zou je, als je het even niet doorhebt, dagen niet aan het updaten zijn. Je zou ook gewoon je Windows machine aan het restarten kunnen zijn (doe je nou eenmaal net ff iets minder vaak ok UNIX), waardoor het script ook niet goed afgesloten was. Ik heb retrieve.php ook wel eens gewoon echt zien hangen.

M.a.w, --force in een cronjob/schedule is zo gek nog niet, als je er zeker van wilt wezen dat er echt altijd geupdate wordt. Er is zelfs ook nog een --reallyforce parameter, maar daar heb ik me nooit aan gewaagd.

[mesa57]

Nou, niet exact. retrieve kijkt ook of de vorige instantie (nowrunning) meer dan 900 seconden in het verleden ligt. Zo ja, dan start hij gewoon.
Het tijdstip wordt iedere keer gereset als er een groepje headers is opgehaald.
De optie --reallyforce bestaat niet.

[ Voor 7% gewijzigd door mesa57 op 07-06-2016 17:24 ]

[albatross]

mesa57 schreef op dinsdag 07 juni 2016 @ 17:23:
Nou, niet exact. retrieve kijkt ook of de vorige instantie (nowrunning) meer dan 900 seconden in het verleden ligt. Zo ja, dan start hij gewoon.
Het tijdstip wordt iedere keer gereset als er een groepje headers is opgehaald.
De optie --reallyforce bestaat niet.

Niet meer, kennelijk. Google er maar eens op. Kan me nog discussies herinneren tussen --force en --reallyforce.

Weet niet precies waarom we ineens verzand raakten in een discussie over --force, overigens, maar mijn InnoDB assertion probleem, waar ik voor aanvankelijk voor kwam, is iig opgelost. En heb zelf nooit, in al de ca. 6 jaar dat ik al spotweb op een server (FreeBSD) had draaien, enig nadelig effect ondervonden van --force. Maar met de Windows scheduler heb ik het ook niet echt meer nodig in een task.

[mesa57]

Maar --force in een crontab of scheduler is dus niet nodig is mijn conclusie.

[Satom]

Inderdaad, is een mogelijkheid die standaard niet gebruikt hoeft te worden, weet niet precies hoe het werkt en of het mogelijk is om een mail te laten sturen bij een Exception/fout (ga van het weekend Spotweb weer even uit het stof halen).

[albatross]

mesa57 schreef op woensdag 08 juni 2016 @ 17:59:
Maar --force in een crontab of scheduler is dus niet nodig is mijn conclusie.

En die conclusie deel ik nu dus. Er is niets meer dat --force doet dat de Windows task scheduler niet veel netter kan doen. En retrieve.php zelf lijkt ook een stukje slimmer geworden, met die timestamps en zo. Loopt nu al een paar dagen hier zonder --force, en blijft gewoon prima updaten.

Bovendien heb ik nog eens op nagelezen, en hoewel wat ik zei klopt, dat er geen database corruptie plaats kan vinden wanneer er meerdere retrieve.php procesen tegelijk lopen (vanwege de transaction safe natuur van InnoDB), zag ik, over timestamps gesproken, dat je comments tijdstippen wel onjuist kunnen worden (wanneer er later weer hetzelfde commentaar toegevoegd wordt aan de database). Weer een goede reden omdat --force toch maar niet meer te gebruiken in een crontab/scheduler omgeving.

[albatross]

Satom schreef op woensdag 08 juni 2016 @ 18:02:
Inderdaad, is een mogelijkheid die standaard niet gebruikt hoeft te worden, weet niet precies hoe het werkt en of het mogelijk is om een mail te laten sturen bij een Exception/fout (ga van het weekend Spotweb weer even uit het stof halen).

Zat vanmiddag (om duidelijke reden) nog net even te snuffen in retrieve.php. En volgens mij schrijft ie wel naar de syslog facility bij een fout; dus ergens in /var/log/messages (of waar dat op jouw systeem zich ook bevindt) zul je berichten dus wel kunnen vinden.

[Satom]

albatross schreef op woensdag 08 juni 2016 @ 18:14:
[...]


Zat vanmiddag (om duidelijke reden) nog net even te snuffen in retrieve.php. En volgens mij schrijft ie wel naar de syslog facility bij een fout; dus ergens in /var/log/messages (of waar dat op jouw systeem zich ook bevindt) zul je berichten dus wel kunnen vinden.

Eventueel zelf even instellen dat je een mail ervan krijgt, o.i.d. Dan weet je gelijk wanneer er iets niet goed gaat

[albatross]

Satom schreef op woensdag 08 juni 2016 @ 18:50:
[...]
Eventueel zelf even instellen dat je een mail ervan krijgt, o.i.d. Dan weet je gelijk wanneer er iets niet goed gaat

Wist niet dat dat ook kon. Weet ook niet of ik wel van alle fouten een melding wil. Eigenlijk van bijna geen, nu ik er over nadenk. Zelfs fatal errors (zoals niet kunnen connecten met news server) kunnen gewoon transient van aard zijn. PHP crashes zou ik wellicht wel een mail van willen; of database errors. Anders niet, denk ik.

[mesa57]

Volgens mij krijg je een mail van alle output, telkens als het proces draait. Dus ook als het goed gaat.

[duiveltje666]

Satom schreef op maandag 06 juni 2016 @ 16:56:
Het is inderdaad met 7.0 i.p.v. 5. Wat ik zelf altijd doe is even kijken op de site van Debian (ik gebruik erg veel Debian) wat de juiste naam van de pakketten zijn

Waarom geen "apt-cache search php7 | more" ?

[Satom]

mesa57 schreef op woensdag 08 juni 2016 @ 19:21:
Volgens mij krijg je een mail van alle output, telkens als het proces draait. Dus ook als het goed gaat.

Dat zou natuurlijk ook gewoon ideaal, de laatste keer dat ik spotweb had, stond er ook geen mailserver/smtp ingesteld Ik zal er eens naar kijken.

albatross schreef op woensdag 08 juni 2016 @ 19:10:
[...]


Wist niet dat dat ook kon. Weet ook niet of ik wel van alle fouten een melding wil. Eigenlijk van bijna geen, nu ik er over nadenk. Zelfs fatal errors (zoals niet kunnen connecten met news server) kunnen gewoon transient van aard zijn. PHP crashes zou ik wellicht wel een mail van willen; of database errors. Anders niet, denk ik.

Met een beetje PHP kennis kun je alles realiseren en idd moet je niet alles in de mail willen hebben, ik zat meer te denken aan een globale mail met 'gelukt' of 'mislukt'. Dan kun je zelf de logs wel gaan bekijken waarom het fout gegaan is.

duiveltje666 schreef op woensdag 08 juni 2016 @ 21:01:
[...]

Waarom geen "apt-cache search php7 | more" ?

Vaak als ik er aan denk of iets kan of wil weten of een pakket bestaat, heb ik de browser toch al open staan en de server vaak niet

[SaintNick]

Ik heb net met succes Spotweb op mijn Synology DS216+ gezet, alles prima.
Alleen heb ik een foutje gemaakt voor de eerste retrieve. Ik had gekozen ophalen vanaf 1 september 2013 (1200 dagen vanaf nu), maar ik had ook laten staan na 500 dagen alles weggooien. Dus het eindresultaat is dat alles tussen 1200 dagen en 500 dagen wel is opgehaald maar meteen is weggegooid.

Wat kan ik nu doen om toch alle spots vanaf 1200 dagen binnen te halen?

Database droppen/weggooien?
De hele install opnieuw doorlopen?

EDIT: Gewoon uninstall (incl database) en opnieuw installeren. Klaar.

[ Voor 6% gewijzigd door SaintNick op 13-06-2016 01:00 . Reden: Oplossing gevonden ]

[ShadowBumble]

Ik heb mijn webserver opnieuw geinstalleerd ( Debian + NGINX + PHP7-FPM + mariaDB ) netjes een verse git pull gedaan van de repo. Echter na updaten van de database, krijgen ik alleen nog maar een blank scherm zodra ik inlog in spotweb.

Nergens krijg ik een error te zien. Hebben jullie dit vaker gezien ?

EDIT:

Uiteindelijk opgelost, er blijk iets raars in de template te zitten op het moment dat je tijdens de installatie voor een "Shared" setup gaat. Doe je exact dezelfde setup maar kies je voor "Public" dan zijn er geen problemen.

[ Voor 28% gewijzigd door ShadowBumble op 16-06-2016 14:50 ]

[mesa57]

@ShadowBumble : kun je daar evt. een issue op github voor aanmaken ?

[jjust]

Edit: nvm. algemene update van het systeem en een reboot en de problemen zijn opgelost.


Vandaag problemen met retrieven. Dus dacht doe even een update met git pull en php upgrade-db.php daarna werkte de retrieve weer.Echter nu krijg ik ipv comments een lange error. De error begint met;;

Notice: Undefined index: prevMsgids in /var/www/spotweb/templates/we1rdo/comment.inc.php on line 18

Warning: Missing argument 6 for Services_Actions_GetComments::getSpotComments(), called in /var/www/spotweb/lib/SpotTemplateHelper.php on line 81 and defined in /var/www/spotweb/lib/services/Actions/Services_Actions_GetComments.php on line 44

Notice: Undefined variable: language in /var/www/spotweb/lib/services/Actions/Services_Actions_GetComments.php on line 50

Warning: Invalid argument supplied for foreach() in /var/www/spotweb/lib/services/Providers/Services_Providers_Comments.php on line 41

Notice: Undefined variable: language in /var/www/spotweb/lib/services/Actions/Services_Actions_GetComments.php on line 67

Notice: Undefined index: prevMsgids in /var/www/spotweb/templates/we1rdo/comment.inc.php on line 18

Warning: Missing argument 6 for Services_Actions_GetComments::getSpotComments(), called in /var/www/spotweb/lib/SpotTemplateHelper.php on line 81 and defined in /var/www/spotweb/lib/services/Actions/Services_Actions_GetComments.php on line 44

Systeem

php 5.5.9-1 Ubuntu 4.14
MySQL 5.5.47

Meer mensen met problemen?

[ Voor 3% gewijzigd door jjust op 19-06-2016 16:50 ]

[mesa57]

Overigens slaat de fout die je had precies op wijzigingen in de laatste release.
In die release wordt verwijder berichten van spotnet 1.8.x en 2.0.0.x ondersteund zodat je geen dubbele spots meer te zien krijgt. Spotters kunnen namelijk in spotnet nu hun eigen spots verwijderen c.q. bewerken.

[ShadowBumble]

mesa57 schreef op zaterdag 18 juni 2016 @ 09:43:
@ShadowBumble : kun je daar evt. een issue op github voor aanmaken ?

Ja zal er vanmiddag wel even eentje voor aanmaken. Kan alleen niet de exacte oorzaak geven maar wel hoe je het reproduceert.

[mesa57]

Dat laatste is wellicht het belangrijkste.

[jjust]

mesa57 schreef op zondag 19 juni 2016 @ 22:04:
Overigens slaat de fout die je had precies op wijzigingen in de laatste release.
In die release wordt verwijder berichten van spotnet 1.8.x en 2.0.0.x ondersteund zodat je geen dubbele spots meer te zien krijgt. Spotters kunnen namelijk in spotnet nu hun eigen spots verwijderen c.q. bewerken.

Spotweb werkt weer. Alleen kan ik niet door het linker menu scrollen. Het linker menu pas niet helemaal op het scherm maar ik kan niet naar onder schrollen om op de retrieve button te klikken. Als ik mijn tablet een kwartslag draai past het wel en kan ik op de knop klikken. Geen ramp maar dacht meld het toch even.

[mesa57]

Helaas kan ik dat niet testen, want er is geen tablet te vinden hier in huis (raar hè).
Als je een issue op github opent, kijkt misschien iemand anders ernaar (hoewel het oorverdovend stil geworden is daar).
Btw. je kunt de filters wel inklappen, misschien helpt dat ?

[ Voor 12% gewijzigd door mesa57 op 21-06-2016 21:43 ]

[alesandro_46]

Je kan het linker menu ook "loskoppelen" met de punaise (linksboven in het scherm). Als de punaise 'vast' staat (horizontaal) dan blijft het linker menu staan, zet je hem 'los' (verticaal) dan kan schuift het linker menu mee tijdens het scrollen.

Verder heb ik inderdaad ook een aantal filters ingeklapt, zodat het hele linker menu zichtbaar is.

[jjust]

Het was inderdaad de punaise. Nooit geweten maar het werkt nu dus weer.

[Kavaa]

<sup>Hi,
Ik weet niet of dit al een keer voorbij is gekomen maar kon het niet terug vinden.
Ik heb een probleem met mijn Spotweb en ik krijg het niet meer werkend.
Heb laatst een update gedaan nieuwe git clone bla bla werkte allemaal prima.
Echter niet op gelet toen maar de images laden niet meer.
Verder werkt alles prima.

Ook na een reset van de database / herinstallatie werkt het niet.

Heeft een van jullie een idee.
Ook deze optie heb ik al geprobeerd: http://www.synology-forum...eb-geen-plaatjes-meer-op/

Systeem:
CentOS
Standaard Webserver etc.
Spotweb

Zie hier de images:
http://d.pr/i/1iItp
http://d.pr/i/11lIW
http://d.pr/i/1kBeG

Het rondje blijft dus draaien...

Iemand een idee?</sup>

NEVERMIND gevonden.

Door de update zijn de rechten van de mappen veranderd.
een:

code:

chmod 0777 cache

Loste het probleem op.

[ Voor 9% gewijzigd door Kavaa op 24-06-2016 15:33 ]

[Appelpie3000]

Even een kopie van een post uit het synology topic: https://gathering.tweaker...message/47404981#47404981

Ik zit met een probleem waar ik al enige tijd mee bezig ben, maar het wil niet echt vlotten.

Ik krijg spotweb niet 100% goed draaiende op mn DS716+. Ik kan spotweb gewoon benaderen via server/spotweb, kan spots binnenhalen en downloaden via de webinterface.

Ik krijg echter de api niet werkend met de http://server/spotweb/api?t=c, want dan krijg ik een 404 error.

Ik draai DSM 6.0.1-7393 Update 1 met nginx en heb de volgende instellingen in /etc/nginx/sites-enabled/spotweb gezet:

code:

server{
location /spotweb {
if ($uri !~ "api/"){
rewrite api/?$ /spotweb/index.php?page=newznabapi last;
}
}
}

Ik heb het al zonder bovenstaande instellingen geprobeerd, met, de naam gewijzigd naar spotweb.conf, maar niets lijkt te werken.

Na een tip van kraades geprobeerd om bovenstaande code in /etc/nginx/conf.d/ te zetten. Minus de "server{ ... }" dan, maar ook dat werkt niet

Jullie nog ideeën?

[Madshark]

Heb hier al een poosje een Spotweb draaien op Ubuntu, na wat slag en stoot werkt het nu eigenlijk toch wel redelijk prima.
Echter ben ik onlangs tot conclusie gekomen dat ik toch komplete spotters mis. Zo nu en dan kijk ik ook wel eens op andere publieke Spotweb servers (geen id of ik deze hier zomaar mag linken), en daar zie ik bijvoorbeeld wel hun spots er tussen staan.

Uiteindelijk maar eens de hele VM gewiped en weer vanaf grond af aan alles opgebouwd. Deze keer met XSNews als feed provider. (was Astranews)
Maar helaas, nu ook weer geen spots van bijvoorbeeld Kenji (g1q5Q). Zou dit specifiek met Astranews en XSnews te maken hebben, of is het toch Spotweb gerelateerd ? (wellicht blacklisted?)

[outlandos]

Het is mij helaas echt te ingewikkeld om het werkend te krijgen op mijn Synology NAS. Zou er geen package kunnen komen voor leken zoals ik?

[Meneer iCy]

Madshark schreef op dinsdag 28 juni 2016 @ 22:15:
Maar helaas, nu ook weer geen spots van bijvoorbeeld Kenji (g1q5Q). Zou dit specifiek met Astranews en XSnews te maken hebben, of is het toch Spotweb gerelateerd ? (wellicht blacklisted?)

Geen algemene blacklist en geen astranews oorzaak, overigens heeft hij alleen maar 18+ materiaal.

[mesa57]

En dat kun je aan of uitzetten in je preferences.

[Verwijderd]

Madshark schreef op dinsdag 28 juni 2016 @ 22:15:
Maar helaas, nu ook weer geen spots van bijvoorbeeld Kenji (g1q5Q). Zou dit specifiek met Astranews en XSnews te maken hebben, of is het toch Spotweb gerelateerd ? (wellicht blacklisted?)

Ik verwacht dat alle resellers van Cheapnews en XSNews hier last van hebben. Bij deze providers zie je niet de spots die geplaatst zijn met spotweb. Het betreft o.a. de spotters: Bassie (1v8DrA), hotmama (FOFVxA), hzuu (3hrsOQ) en Kenji (g1q5Q). Ik merk hetzelfde bij Bulknews en NewsXS.

Als je met het programma Xnews in de groep free.pt kijkt, dan kun je wel de headers van deze spotters zien. Wat mij hierbij opvalt is dat de opmaak van het "From field" er bij deze spotters anders uitziet. Mogelijk veroorzaakt dit het probleem.

[Madshark]

icy schreef op woensdag 29 juni 2016 @ 10:18:
[...]

Geen algemene blacklist en geen astranews oorzaak, overigens heeft hij alleen maar 18+ materiaal.

Klopt, ik nam deze spotter even als voorbeeld, mis er inderdaad meer.

Verwijderd schreef op woensdag 29 juni 2016 @ 11:15:
[...]


Ik verwacht dat alle resellers van Cheapnews en XSNews hier last van hebben. Bij deze providers zie je niet de spots die geplaatst zijn met spotweb. Het betreft o.a. de spotters: Bassie (1v8DrA), hotmama (FOFVxA), hzuu (3hrsOQ) en Kenji (g1q5Q). Ik merk hetzelfde bij Bulknews en NewsXS.

Als je met het programma Xnews in de groep free.pt kijkt, dan kun je wel de headers van deze spotters zien. Wat mij hierbij opvalt is dat de opmaak van het "From field" er bij deze spotters anders uitziet. Mogelijk veroorzaakt dit het probleem.

[afbeelding]

exactly !
Dan komt natuurlijk de vraag, welke usenet provider is dan het meest geschikt als feed provider voor Spotweb ? Er is ooit al eens Astraweb geadviseerd vanwege block accounts, maar die laat helaas ook weer (andere) spots schieten. Eweka heeft helaas alleen accounts vanaf 7,50 per maand, wat weer een beetje te gortig is als je al XSNews, Cheapnews en Nextgen geabonneerd bent.

Zijn er overigens nog mogelijkheden om met een andere provider de missing spots opnieuw binnen te halen, of rest er niets anders dan de hele database te droppen, en alles weer overnieuw binnentrekken ?

[ Voor 6% gewijzigd door Madshark op 29-06-2016 17:19 ]

[Verwijderd]

Madshark schreef op woensdag 29 juni 2016 @ 17:17:
Dan komt natuurlijk de vraag, welke usenet provider is dan het meest geschikt als feed provider voor Spotweb ? Er is ooit al eens Astraweb geadviseerd vanwege block accounts, maar die laat helaas ook weer (andere) spots schieten. Eweka heeft helaas alleen accounts vanaf 7,50 per maand, wat weer een beetje te gortig is als je al XSNews, Cheapnews en Nextgen geabonneerd bent.

Voor € 2,00 heb je een blockaccount van 10GB bij Tweaknews. Voor zover ik heb kunnen beoordelen, haalt deze alles binnen. Je kunt Tweaknews ook 10 dagen gratis proberen.

In je download programma gebruik je dan één van je andere abonnementen.

[mesa57]

Verwijderd schreef op woensdag 29 juni 2016 @ 11:15:
[...]
Ik verwacht dat alle resellers van Cheapnews en XSNews hier last van hebben. Bij deze providers zie je niet de spots die geplaatst zijn met spotweb. Het betreft o.a. de spotters: Bassie (1v8DrA), hotmama (FOFVxA), hzuu (3hrsOQ) en Kenji (g1q5Q). Ik merk hetzelfde bij Bulknews en NewsXS.

Mooie analyse !
Spotweb maakt gebruikt van 1024 bits rsa moduli (ipv 384 in spotnet en 512 in spotlite).
Die wordt in de FROM: header geplaatst om de spot te verifieeren.
Bij cheapnews zag ik nu dat als de headers via XOVER worden binnengehaald, de FROM: line afgebroken wordt. Daardoor kan spotnet (en ook andere spotclients) de spot niet meer verifieeren.

code:

Header[2]=Kenji <-prCbdh8ckP9B-pvscgDRimeCZu31cb3wJPw-pomk4ab8t8FDphLBDvJz-squnjdD1jUVL-pv7WEDCc8g9h6foNUxRGD7EkH4cof-sG4YGQUATfZze-sQjA-sS-sEFCA-pjt-prPJcQjACUamrMNcSU3tVWBOpgdxGzIw7rImqhQk9jp-swkR80=.pAp9-sta9b-ptOEbGmAROXPEMUxBAqFBtyDQ4UG6h2QTg76-s6tUnmLI6PfJUxhiKkRgWNAMqLVo7MUMPv1BO-sGxClNYnd-sWrFy7FqxIP1 <-- Vanaf hier ontbreekt het e.e.a.

[aanvulling]
Nog even geteld : de from header wordt afgebroken op 300 bytes
[/aanvulling]

[ Voor 4% gewijzigd door mesa57 op 29-06-2016 21:49 ]

[Madshark]

Verwijderd schreef op woensdag 29 juni 2016 @ 18:18:
[...]


Voor € 2,00 heb je een blockaccount van 10GB bij Tweaknews. Voor zover ik heb kunnen beoordelen, haalt deze alles binnen. Je kunt Tweaknews ook 10 dagen gratis proberen.

In je download programma gebruik je dan één van je andere abonnementen.

Ik kan intussen bevestigen dat je verhaal helemaal klopt !!
Spotweb database verwijderd, nieuwe aangemaakt, laten vullen met Tweaknews, en inderdaad, alle ontbrekende spots komen nu ook binnen.
Thnxs !!!

[Meneer iCy]

Madshark schreef op woensdag 29 juni 2016 @ 17:17:
[...]


Klopt, ik nam deze spotter even als voorbeeld, mis er inderdaad meer.


[...]


exactly !
Dan komt natuurlijk de vraag, welke usenet provider is dan het meest geschikt als feed provider voor Spotweb ? Er is ooit al eens Astraweb geadviseerd vanwege block accounts, maar die laat helaas ook weer (andere) spots schieten. Eweka heeft helaas alleen accounts vanaf 7,50 per maand, wat weer een beetje te gortig is als je al XSNews, Cheapnews en Nextgen geabonneerd bent.

Zijn er overigens nog mogelijkheden om met een andere provider de missing spots opnieuw binnen te halen, of rest er niets anders dan de hele database te droppen, en alles weer overnieuw binnentrekken ?

Maar het vreemde is dat ik kenji dus wel zie en ik heb ook Astraweb en spotweb op Ubuntu

[pven]

outlandos schreef op woensdag 29 juni 2016 @ 09:54:
Het is mij helaas echt te ingewikkeld om het werkend te krijgen op mijn Synology NAS. Zou er geen package kunnen komen voor leken zoals ik?

Dat bestaat al, kijk eens in het topic over de Synology-packages.

Verwijderd schreef op woensdag 29 juni 2016 @ 11:15:
[...]


Ik verwacht dat alle resellers van Cheapnews en XSNews hier last van hebben. Bij deze providers zie je niet de spots die geplaatst zijn met spotweb. Het betreft o.a. de spotters: Bassie (1v8DrA), hotmama (FOFVxA), hzuu (3hrsOQ) en Kenji (g1q5Q). Ik merk hetzelfde bij Bulknews en NewsXS.

Als je met het programma Xnews in de groep free.pt kijkt, dan kun je wel de headers van deze spotters zien. Wat mij hierbij opvalt is dat de opmaak van het "From field" er bij deze spotters anders uitziet. Mogelijk veroorzaakt dit het probleem.

[afbeelding]

Raar ... want volgens mij filteren ze niet specifiek op users van Spotweb. Zie het het niet in Spotweb zelf, of met het programma waarmee je download?

[ Voor 58% gewijzigd door pven op 30-06-2016 08:05 ]

[Verwijderd]

pven schreef op donderdag 30 juni 2016 @ 08:02:
Raar ... want volgens mij filteren ze niet specifiek op users van Spotweb. Zie het het niet in Spotweb zelf, of met het programma waarmee je download?

Zie dit bericht van mesa57.
Daarin wordt uitgelegd wat er bij deze providers verkeerd gaat.

[Verwijderd]

icy schreef op donderdag 30 juni 2016 @ 06:29:
Maar het vreemde is dat ik kenji dus wel zie en ik heb ook Astraweb en spotweb op Ubuntu

Madshark schreef op woensdag 29 juni 2016 @ 17:17:
Er is ooit al eens Astraweb geadviseerd vanwege block accounts, maar die laat helaas ook weer (andere) spots schieten.

Astraweb is geen reseller van Cheapnew of XSNews en heeft volgens mij dit probleem niet.
Waarschijnlijk miste hij met Astraweb andere spots.

[pven]

Verwijderd schreef op donderdag 30 juni 2016 @ 08:40:

[...]


Astraweb is geen reseller van Cheapnew of XSNews en heeft volgens mij dit probleem niet.
Waarschijnlijk miste hij met Astraweb andere spots.

Astraweb staat inderdaad op haar zelf, heeft geen afhankelijkheden met andere usenet-grootheden (vandaar mijn keuze voor hen).

Als ik iets op moet zoeken bij Astraweb: laat het weten.

[Meneer iCy]

Verwijderd schreef op donderdag 30 juni 2016 @ 08:40:
[...]


[...]


Astraweb is geen reseller van Cheapnew of XSNews en heeft volgens mij dit probleem niet.
Waarschijnlijk miste hij met Astraweb andere spots.

Madshark schreef op dinsdag 28 juni 2016 @ 22:15:
Maar helaas, nu ook weer geen spots van bijvoorbeeld Kenji (g1q5Q). Zou dit specifiek met Astranews en XSnews te maken hebben, of is het toch Spotweb gerelateerd ? (wellicht blacklisted?)

Hij heeft het met XSnews en met Astraweb zoals ik volgens zijn informatie begrijp

Tevens alle andere genoemde namen zie ik ook steeds spots van.

[ Voor 4% gewijzigd door Meneer iCy op 30-06-2016 09:53 ]

[Verwijderd]

icy schreef op donderdag 30 juni 2016 @ 09:51:
Hij heeft het met XSnews en met Astraweb zoals ik volgens zijn informatie begrijp

@Madshark: Waren je problemen met Astraweb en XSNews precies hetzelfde, of ging het om verschillende spots/spotters?

[outlandos]

pven schreef op donderdag 30 juni 2016 @ 08:02:
[...]

Dat bestaat al, kijk eens in het topic over de Synology-packages.


[...]

Vanavond eens naar kijken dan. Zou Spotweb namelijk graag toevoegen als bron om films in op te zoeken voor CP en SichRage.

[Madshark]

Verwijderd schreef op donderdag 30 juni 2016 @ 10:23:
[...]


@Madshark: Waren je problemen met Astraweb en XSNews precies hetzelfde, of ging het om verschillende spots/spotters?

Oh, was er blijkbaar niet echt helemaal duidelijk over. Nee, bij Astraweb had ik last van random spots die niet binnenkwamen, leek erop dat dit bij sommige spotters vaker voorkwam dan bij anderen. Als ik bijv. een search deed op een serie, ontbrak er soms een aflevering, of soms de hele serie, terwijl ik deze met exact dezelfde search het wel terug vond in 1 van de publieke Spotweb servers.
Vandaar in eerste instantie de overstap naar Cheap, hierna XSNews.
Bij XSNews en Cheapnews was het probleem consistent, vrijwel alle spots van hierboven genoemde spotters komen dan in zijn geheel niet door.

[ Voor 9% gewijzigd door Madshark op 30-06-2016 15:53 ]

[pven]

Verwijderd schreef op woensdag 29 juni 2016 @ 11:15:
[...]

Het betreft o.a. de spotters: Bassie (1v8DrA)

Laatste spot die ik zie: 7/4/2010

hotmama (FOFVxA)

Laatste spot die ik zie: 22/5/2015

hzuu (3hrsOQ)

Laatste spot die ik zie: 12/2/2016

Kenji (g1q5Q).

Laatste spot die ik zie: 27/6/2016

Maar ... ik heb een nabewerking lopen die de categorie 'Erotica' (z3) hard uit de database verwijderd. En volgens mij zijn dit vooral spotters die erotiek plaatsen?

Voor het beeld mijn nabewerking (dit voer ik meteen uit na een retrieve):

code:

select count(*) before_del from spots;
DELETE FROM spots, spotsfull, commentsxover USING spots
LEFT JOIN spotsfull ON spots.messageid=spotsfull.messageid
LEFT JOIN commentsxover ON spots.messageid=commentsxover.nntpref
WHERE category = '0' and subcatz = 'z3|';
select count(*) after_del_ero from spots;
DELETE FROM spots WHERE reportcount >= 5;
select count(*) after_del_trolls from spots;
DELETE FROM spots, spotsfull, commentsxover USING spots
LEFT JOIN spotsfull ON spots.messageid=spotsfull.messageid
LEFT JOIN commentsxover ON spots.messageid=commentsxover.nntpref
WHERE poster = 'Bassie';
select count(*) after_del_Bassie from spots;

In het kort:
• erotica wordt verwijderd
• spots met meer dan vier reports worden verwijderd
• Bassie heb ik eruit gegooid omdat die alleen maar van die forward-URL's plaatst (schiet mij nu te binnen)

[Madshark]

Ik zal even mijn resultaten erbij zetten, na een full retrieve van Tweaknews.

pven schreef op donderdag 30 juni 2016 @ 16:16:
[...]

Laatste spot die ik zie: 7/4/2010

Laatste post 28/6/2016

[...]

Laatste spot die ik zie: 22/5/2015

Laatste post 29/06/2016 (gisteren dus)

[...]

Laatste spot die ik zie: 12/2/2016

Hier ook 12/2/2016

[...]

Laatste spot die ik zie: 27/6/2016

Vandaag, 26 minuten geleden.

[mesa57]

Ik heb kontakt gehad met Cheapnews, nu wil de support desk weten of de from: header afgekapt wordt bij het plaatsen van de spot of het lezen ervan. Grmbl....
Nah ja, terechte vraag natuurlijk.

[Verwijderd]

Als de from: header al bij het plaatsen van een spot afgekapt zou worden, dan horen andere providers (Highwinds Network Group, Astraweb, XS4ALL etc.) toch hetzelfde probleem te hebben?

[ Voor 6% gewijzigd door Verwijderd op 30-06-2016 20:00 ]

[mesa57]

Leek me ook. En een kort testje wijst uit dat het ook zo is. De from: header wordt alleen afgekapt bij een XOVER command bij de betreffende providers.

[Madshark]

Intussen Spotweb goed draaien, deze keer met een goede database, dus geen missing spots meer
Maar mijn SR wil nog steeds helemaal niets vinden uit mijn Spotweb. Zelfs een helemaal default out-of-the-box SR installatie (op een Synology), zonder required words etc, vind gewoon niets.
Als testje hiernaast nog even Sonarr terug op een Synology gezet, die krijgt wel search hit's uit mijn Spotweb database, maar helaas kan ie niets met hits van een bepaalde voorkeur releasegroup (unkown series) Dus dat blijft een no-go.

Intussen begin ik aardig moedeloos te worden van het niet echt fijn werken van SR met de geïnstalleerde Spotweb, het zou erg handig zijn als deze mijn series automatisch kon bijhouden.
Hier misschien een tweaker die mij per PM een test accountje kan lenen op zijn/haar Spotweb database waarvan bekend is dat deze zou moeten werken met SR ? Zodoende kan ik dan gaan uitsluiten ofdat dit nu aan mijn SR ligt, of toch de oorzaak ergens in mijn Spotweb moet terug vinden (ondanks dat Sonarr wel iets uit kan halen)

[ikkeenjij36]

Hallo na een tijdje weer eens op mijn spotweb gekeken op mijn syno.
Nu krijg ik na een bepaald aantal spots dit te zien:Notice: Undefined index: start in /volume1/web/spotweb/lib/SpotTiming.php on line 93
Met daaronder een heleboel lijnen tekst.
Hoe kom ik hier vanaf of hoe herstel ik het weer?
Mijn nzbs worden wel netjse doorgestuurd naar sab.

[mesa57]

Bij instellingen kun je spottiming afzetten.

[ikkeenjij36]

mesa57 schreef op maandag 11 juli 2016 @ 22:07:
Bij instellingen kun je spottiming afzetten.

[afbeelding]

En bedankt weer voor de oplossing

[Kozzmozz]

Nog iemand problemen met het binnenhalen van nieuwe spots via Synology NAS?
Teller zit al aan dag 1 + 20 uur

*UPDATE: foutief paswoord op Spotweb ingegeven

[ Voor 20% gewijzigd door Kozzmozz op 15-07-2016 12:26 ]

[jdwrist]

Ik ben rustig aan bezig om spotweb op mijn synology te installeren. Nu heb ik het volgens de op google te vinden stappen geïnstalleerd

Webcliënt --> na installatie php aangezet en mysql aangevinkt in het lijstje

Mariadb --> hier niets aan gedaan

Spotweb --> myip/spotweb/install.php en hier alle stappen in gevolgd

Bij het starten van spotweb/install.php doorloop ik alle stappen waarbij je eindigt dat je een lijstje met commando's in een tekstbestand moet zetten en deze op te slaan als dbsettings.inc.php nu weet ik alleen niet waar dat ik deze op moet slaan op mijn NAS

Na deze stappen te hebben gedaan wil ik spotweb opstarten en dan krijg ik de melding er geen db aanwezig is en dat ik die aan kan maken door wederom de spotweb/install.php te volgen?? Heeft dit te maken met de dbsettings.inc.php die dus nog niet op de juiste plaats staan?

spotweb/retrieve.php is dus ook nog niet te gebruiken laat staan spotweb als zodoende.

Ik hoop dat iemand mij verder kan helpen!

[mesa57]

Laatst is daar een hele thread over geweest op het synology.nl forum.
Ik heb ook nog aan die discussie deelgenomen. Er is toen ook een sticky met een handleiding aangemaakt.

http://www.synology-forum...jg-spotweb-niet-werkende/

[ Voor 16% gewijzigd door mesa57 op 31-07-2016 11:31 ]

[jdwrist]

mesa57 schreef op zondag 31 juli 2016 @ 11:28:
Laatst is daar een hele thread over geweest op het synology.nl forum.
Ik heb ook nog aan die discussie deelgenomen. Er is toen ook een sticky met een handleiding aangemaakt.

http://www.synology-forum...jg-spotweb-niet-werkende/

Thanks probleem was dat ik het bestand in de /volume1/web had gezet ipv /volume1/web/spotweb

Ik kwam deze tutorial tegen.

Mijn database is inmiddels aan het updaten als ik het goed heb duurt dit nog wel een tijdje.

Heeft iemand enig idee hoe ik de retentie aan kan passen? Via Instellingen wijzigen in Spotweb zie ik geen tabje retentie

[Tuxinator]

jokapo schreef op zondag 31 juli 2016 @ 21:30:
[...]
Heeft iemand enig idee hoe ik de retentie aan kan passen? Via Instellingen wijzigen in Spotweb zie ik geen tabje retentie

Ga naar Settings > (tab) Retrieve en pas daar "Retention on spots (in days)" aan. Zie punt 4.4.3 van je handleiding.

[jdwrist]

Tuxinator schreef op zondag 31 juli 2016 @ 21:37:
[...]

Ga naar Settings > (tab) Retrieve en pas daar "Retention on spots (in days)" aan. Zie punt 4.4.3 van je handleiding.

As said, Via Instellingen wijzigen in Spotweb zie ik geen tabje retentie (zie linkje) https://drive.google.com/...3gYTRGqOnUZUxWRy10S1pHcms

[ Voor 12% gewijzigd door jdwrist op 31-07-2016 21:46 ]

[Tuxinator]

jokapo schreef op zondag 31 juli 2016 @ 21:39:
[...]


As said, Via Instellingen wijzigen in Spotweb zie ik geen tabje retentie (zie linkje) https://drive.google.com/...3gYTRGqOnUZUxWRy10S1pHcms

Je zit verkeerd. Je zit in "Change preferences", je moet de "Settings" hebben.

[jdwrist]

ik kan alleen de voorkeuren veranderen maar niet mijn settings? sterker nog onder voorkeuren heb ik geen knop settings

[ Voor 31% gewijzigd door jdwrist op 31-07-2016 22:03 ]

[Tuxinator]

Dan heb je waarschijnlijk niet genoeg rechten. Je moet lid zijn van de "Administrators" groep om bij die settings te kunnen komen.

[jdwrist]

Op mijn NAS heb ik een "eigen" naam gemaakt als admin (stukje veiligheid) tijdens de installatie van spotweb heb ik hierbij dezelfde gebruikersnaam als die op mijn Syno gegeven?

[Tuxinator]

Kijk even naar punt 4.4 van je handleiding, in die stap heb je een "administrative user" aangemaakt. Kun je inloggen met de gebruikersnaam en het wachtwoord die je daar hebt opgegeven en kun je dan bij die settings komen? Kun je anders ook eens proberen om in te loggen met de gebruikersnaam admin en het wachtwoord wat je in punt 4.4 hebt opgegeven? En anders eens met de gebruikersnaam admin en het wachtwoord admin?

Wat voor SpotWeb type heb je trouwens gekozen bij dat punt, single user, shared of public?

[ Voor 25% gewijzigd door Tuxinator op 31-07-2016 22:36 ]

[EgMaf]

Nou, ik heb nu ook een probleem met mijn spotweb install.

Spotweb draait bij mij op een W10 client, met Apache, PHP 5.6.23 en MySQL via XAMPP, verder nogal simpele config. Het probleem is nu dat elke keer dat ik retrieve.php draai, de volgende melding komt en MySQL eruit klapt:

Last retrieve at 07/31/16 21:51:45
Retrieving new Spots from server ssl-eu.astraweb.com...
Appr. Message count: 2848637
First message number: 1989963
Last message number: 4838600
Current article number: 4838552

Retrieving 4838552 till 4838601 (parsed: 48, in DB: 1, signed: 48, invalid: 0, r
tntn.skip: 0, mod: 0, full: 0, total: 49) in 0.4 seconds
Processed a total of 49 spots
Finished retrieving spots.

Calculating how many spots are new, done.
Last retrieve at 08/01/16 00:05:45
Retrieving new comments from server ssl-eu.astraweb.com...
PHP Warning: PDOStatement::execute(): MySQL server has gone away in C:\xampp\ht
docs\SpotWeb\lib\dbeng\dbeng_pdo.php on line 57

Warning: PDOStatement::execute(): MySQL server has gone away in C:\xampp\htdocs\
SpotWeb\lib\dbeng\dbeng_pdo.php on line 57
PHP Warning: PDOStatement::execute(): Error reading result set's header in C:\x
ampp\htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php on line 57

Warning: PDOStatement::execute(): Error reading result set's header in C:\xampp\
htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php on line 57


SpotWeb v0.67.28.31 on PHP v5.6.23 crashed

Fatal error occured retrieving reports:
HY000: 2006: MySQL server has gone away


#0 C:\xampp\htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php(146): dbeng_pdo->exec('SELECT
messagei...', Array)
#1 C:\xampp\htdocs\SpotWeb\lib\dao\Base\Dao_Base_Spot.php(821): dbeng_pdo->array
Query('SELECT messagei...')
#2 C:\xampp\htdocs\SpotWeb\lib\services\Retriever\Services_Retriever_Comments.ph
p(337): Dao_Base_Spot->getMaxMessageId('comments')
#3 C:\xampp\htdocs\SpotWeb\lib\services\Retriever\Services_Retriever_Base.php(30
8): Services_Retriever_Comments->getRecentRetrievedMessageIdList()
#4 C:\xampp\htdocs\SpotWeb\retrieve.php(188): Services_Retriever_Base->perform()

#5 {main}

PHP Fatal error: Uncaught SqlErrorException 'HY000: 2006: MySQL server has gone
away' in C:\xampp\htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php(59)
#0 C:\xampp\htdocs\SpotWeb\lib\dao\Base\Dao_Base_UsenetState.php(91): dbeng_pdo-
>exec('UPDATE usenetst...', Array)
#1 C:\xampp\htdocs\SpotWeb\lib\services\Retriever\Services_Retriever_Base.php(26
0): Dao_Base_UsenetState->setRetrieverRunning(false)
#2 C:\xampp\htdocs\SpotWeb\retrieve.php(313): Services_Retriever_Base->quit()
#3 {main}
thrown in C:\xampp\htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php on line 59

Fatal error: Uncaught SqlErrorException 'HY000: 2006: MySQL server has gone away
' in C:\xampp\htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php(59)
#0 C:\xampp\htdocs\SpotWeb\lib\dao\Base\Dao_Base_UsenetState.php(91): dbeng_pdo-
>exec('UPDATE usenetst...', Array)
#1 C:\xampp\htdocs\SpotWeb\lib\services\Retriever\Services_Retriever_Base.php(26
0): Dao_Base_UsenetState->setRetrieverRunning(false)
#2 C:\xampp\htdocs\SpotWeb\retrieve.php(313): Services_Retriever_Base->quit()
#3 {main}
thrown in C:\xampp\htdocs\SpotWeb\lib\dbeng\dbeng_pdo.php on line 59

Als ik upgrade-db.php draai klapt MySQL er ook uit.
Een paar maanden geleden had ik iets vergelijkbaars, maar dat bleek te komen omdat ik PHP7.x gebruikte, en niet de ondersteunde 5.3+ (nu 5.6.23 dus). Dus daar kan het deze keer niet aan liggen.
Destijds heb ik alles opnieuw geinstalleerd, en het draaide nu weer lekker voor een paar maanden met een verse database.

Iemand enig idee wat het kan zijn, of in welke logfiles ik verder zou kunnen spitten?

[CH4OS]

EgMaf schreef op maandag 01 augustus 2016 @ 00:14:

De foutmelding die je krijgt kan o.a. komen omdat de verbinding te lang open staat. Dan sluit MySQL automatisch de verbinding. Dat het te lang duurt, kan verschillende oorzaken hebben, maar de oplossing is dan redelijk eenvoudig: minder spots tegelijk ophalen.

An sich is dat geen probleem, bij elke update haalt het script namelijk alle nieuwe posts binnen die beschikbaar zijn, maar verwerkt er dan dus minder per keer om op te slaan in de datebaste. Ikzelf had bij een usenet provider (weet even niet meer welke) zelfs ingesteld staan, dat hij 10 items per keer moest opslaan, voordat het pas goed werkte en doorliep.

Je kan dus kijken wat het verlagen van die instelling (wat overigens onder ?page=editsettings zit, tabje prestaties) bij jou doet. Mocht dat niet de oplossing zijn, dan is het handig om even de exacte MySQL versie te geven die je gebruikt.

Overigens werkt (bij mij althans) het ophalen via een SSL verbinding ook niet al te best, wellicht kun je dus eens testen zonder SSL, over poort 119.

[ Voor 103% gewijzigd door CH4OS op 01-08-2016 00:28 ]

[EgMaf]

CH40S schreef op maandag 01 augustus 2016 @ 00:23:
[...]
De foutmelding die je krijgt kan o.a. komen omdat de verbinding te lang open staat. Dan sluit MySQL automatisch de verbinding. Dat het te lang duurt, kan verschillende oorzaken hebben, maar de oplossing is dan redelijk eenvoudig: minder spots tegelijk ophalen.

Bedankt voor het meedenken. Helaas klapt MySQL (de daemon/service zelf) er helemaal uit, en moet ik hem handmatig weer starten waarna alles weer goed is totdat ik retrieve.php of upgrade-db.php weer draai.
Het ligt dus niet aan 1 script (want de ander heeft hetzelfde effect), en het is MySQL die er helemaal uit klapt, niet alleen maar de verbinding stopt.

Inmiddels ook myisamchk --force *.myi in de MySQL/DATA/SPOTWEB folder gedraad, maar die checks lopen gewoon door zonder foutmeldingen.

[ Voor 8% gewijzigd door EgMaf op 01-08-2016 00:43 ]

[jdwrist]

Tuxinator schreef op zondag 31 juli 2016 @ 22:26:
Kijk even naar punt 4.4 van je handleiding, in die stap heb je een "administrative user" aangemaakt. Kun je inloggen met de gebruikersnaam en het wachtwoord die je daar hebt opgegeven en kun je dan bij die settings komen? Kun je anders ook eens proberen om in te loggen met de gebruikersnaam admin en het wachtwoord wat je in punt 4.4 hebt opgegeven? En anders eens met de gebruikersnaam admin en het wachtwoord admin?

Wat voor SpotWeb type heb je trouwens gekozen bij dat punt, single user, shared of public?

met admin en mijn ww lukte het inderdaad wel dat ik dat zelf compleet over het hoofd zie zeg

heb hem als shared ingesteld

[CH4OS]

EgMaf schreef op maandag 01 augustus 2016 @ 00:40:
[...]


Bedankt voor het meedenken. Helaas klapt MySQL (de daemon/service zelf) er helemaal uit, en moet ik hem handmatig weer starten waarna alles weer goed is totdat ik retrieve.php of upgrade-db.php weer draai.
Het ligt dus niet aan 1 script (want de ander heeft hetzelfde effect), en het is MySQL die er helemaal uit klapt, niet alleen maar de verbinding stopt.

Inmiddels ook myisamchk --force *.myi in de MySQL/DATA/SPOTWEB folder gedraad, maar die checks lopen gewoon door zonder foutmeldingen.

En wat zeggen de logfiles?

[EgMaf]

CH40S schreef op maandag 01 augustus 2016 @ 08:46:
[...]
En wat zeggen de logfiles?

Welke / waar precies?

[CH4OS]

EgMaf schreef op maandag 01 augustus 2016 @ 09:32:
[...]

Welke / waar precies?

De log files van MySQL; http://stackoverflow.com/...e-mysql-log-file-in-xampp

[EgMaf]

Ok, dus ik heb de MySQL service gestopt in XAMPP, de MySQL_error.log weggehaald, MySQL service weer gestart en retrieve.php gestart. Resultaat: MySQL service is er weer uitgeklapt, retrieve.php geeft dezelfde foutmeldingen als voorheen, en dit is de (nieuwe) MySQL_error.log:

2016-08-01 08:57:26 354 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2016-08-01 8:57:26 852 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-08-01 8:57:26 852 [Note] InnoDB: The InnoDB memory heap is disabled
2016-08-01 8:57:26 852 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2016-08-01 8:57:26 852 [Note] InnoDB: Memory barrier is not used
2016-08-01 8:57:26 852 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-08-01 8:57:26 852 [Note] InnoDB: Using generic crc32 instructions
2016-08-01 8:57:26 852 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2016-08-01 8:57:26 852 [Note] InnoDB: Completed initialization of buffer pool
2016-08-01 8:57:26 852 [Note] InnoDB: Highest supported file format is Barracuda.
2016-08-01 8:57:27 852 [Note] InnoDB: 128 rollback segment(s) are active.
2016-08-01 8:57:27 852 [Note] InnoDB: Waiting for purge to start
2016-08-01 8:57:27 852 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 6938576435
2016-08-01 8:57:27 852 [Note] Plugin 'FEEDBACK' is disabled.
2016-08-01 8:57:27 1812 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-08-01 8:57:27 852 [Note] Server socket created on IP: '::'.
2016-08-01 8:57:27 852 [Note] C:\xampp\mysql\bin\mysqld.exe: ready for connections.
Version: '10.1.13-MariaDB' socket: '' port: 3306 mariadb.org binary distribution
InnoDB: Error: trying to access page number 245252 in space 69,
InnoDB: space name spotweb/commentsxover,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
2016-08-01 08:59:08 1bc0 InnoDB: Assertion failure in thread 7104 in file fil0fil.cc line 5866
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/...cing-innodb-recovery.html
InnoDB: about forcing recovery.
160801 8:59:08 [ERROR] mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.13-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=1
max_threads=1001
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787100 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0xfaf1fe8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
mysqld.exe!my_parameter_handler()
mysqld.exe!my_mb_ctype_mb()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?functype@Item_func_dyncol_create@@UBE?AW4Functype@Item_func@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!??0Global_read_lock@@QAE@XZ()
mysqld.exe!??0Global_read_lock@@QAE@XZ()
mysqld.exe!?get_trg_event_map@Update_rows_log_event@@UAEEXZ()
mysqld.exe!?get_trg_event_map@Update_rows_log_event@@UAEEXZ()
mysqld.exe!?ha_open@handler@@QAEHPAUTABLE@@PBDHI@Z()
mysqld.exe!?open_table_from_share@@YA?AW4open_frm_error@@PAVTHD@@PAUTABLE_SHARE@@PBDIIIPAUTABLE@@_N@Z()
mysqld.exe!?open_table@@YA_NPAVTHD@@PAUTABLE_LIST@@PAVOpen_table_context@@@Z()
mysqld.exe!?recover_from_failed_open@Open_table_context@@QAE_NXZ()
mysqld.exe!?open_tables@@YA_NPAVTHD@@ABUDDL_options_st@@PAPAUTABLE_LIST@@PAIIPAVPrelocking_strategy@@@Z()
mysqld.exe!?open_and_lock_tables@@YA_NPAVTHD@@ABUDDL_options_st@@PAUTABLE_LIST@@_NIPAVPrelocking_strategy@@@Z()
mysqld.exe!??0Table_scope_and_contents_source_st@@QAE@ABU0@@Z()
mysqld.exe!?mysql_execute_command@@YAHPAVTHD@@@Z()
mysqld.exe!?mysql_parse@@YAXPAVTHD@@PADIPAVParser_state@@@Z()
mysqld.exe!?dispatch_command@@YA_NW4enum_server_command@@PAVTHD@@PADI@Z()
mysqld.exe!?do_command@@YA_NPAVTHD@@@Z()
mysqld.exe!?threadpool_process_request@@YAHPAVTHD@@@Z()
mysqld.exe!?tp_end@@YAXXZ()
KERNEL32.DLL!SetUserGeoID()
ntdll.dll!TpSimpleTryPost()
ntdll.dll!EtwNotificationRegister()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUnicodeStringToInteger()
ntdll.dll!RtlUnicodeStringToInteger()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x5160120): SELECT messageid FROM commentsxover ORDER BY id DESC LIMIT 5000
Connection ID (thread ID): 3
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

[CH4OS]

EgMaf schreef op maandag 01 augustus 2016 @ 10:07:

Paar dingen die mij opvallen uit de logfile:

code:

InnoDB: Error: trying to access page number 245252 in space 69,
InnoDB: space name spotweb/commentsxover,
InnoDB: which is outside the tablespace bounds.

code:

160801 8:59:08 [ERROR] mysqld got exception 0x80000003 ;

Wat je kan doen, is even een tijdelijke database toevoegen en daar een tijdelijke Spotweb installatie van maken, kijken of MySQL er dan niet uitklapt. Ik gok van niet, als ik zoek op de laatste foutmelding die ik aanhaal, lijkt het een soort buffer issue te zijn, als dat zo is, kun je kijken hoeveel rek je krijgt als je

mysqlcheck -o <db_schema_name> -u root -p

of

mysqlcheck -o --all-databases -u root -p

doet. Wat de --all-databases schakel doet moge duidelijk zijn, -u zet de username en met -p wordt het wachtwoord gevraagd.

[ Voor 253% gewijzigd door CH4OS op 01-08-2016 12:14 ]

[EgMaf]

Yep, het lijkt inderdaad een issue met de DB (of een record) zelf te zijn, niet met MySQL. Dus ik ben ervan overtuigd dat een verse (tijdelijk of niet) het wel weer zal doen, voor een paar maanden. Maar dan...?

Hieronder het resultaat van mysqlcheck -o. Ik heb ook -c geprobeerd, maar het resultaat is hetzelfde: de service klapt eruit.

C:\xampp\mysql\bin>mysqlcheck -o --all-databases -u ---- -p
Enter password: ********
spotweb.cache
note : Table does not support optimize, doing recreate + analyze instead
status : OK
spotweb.commentsfull
note : Table does not support optimize, doing recreate + analyze instead
status : OK
spotweb.commentsposted
note : Table does not support optimize, doing recreate + analyze instead
status : OK
mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when e
xecuting 'OPTIMIZE TABLE ... '

C:\xampp\mysql\bin>

Ik weet niet of het helpt, maar als ik in phpMyAdmin, links in de treeview, de Spotweb database uitklap, en daarna "commentsxover", klapt de service er weer uit. Ik zie nog wel sub item "Columns", maar "Indexes" verwacht ik wel, maar komt dus niet. Na het opnieuw started van de service kan ik alle andere items wel gewoon uitklappen...

[ Voor 37% gewijzigd door EgMaf op 01-08-2016 13:26 ]

[CH4OS]

EgMaf schreef op maandag 01 augustus 2016 @ 13:13:
Yep, het lijkt inderdaad een issue met de DB (of een record) zelf te zijn, niet met MySQL. Dus ik ben ervan overtuigd dat een verse (tijdelijk of niet) het wel weer zal doen, voor een paar maanden. Maar dan...?

Hieronder het resultaat van mysqlcheck -o. Ik heb ook -c geprobeerd, maar het resultaat is hetzelfde: de service klapt eruit.


[...]


Ik weet niet of het helpt, maar als ik in phpMyAdmin, links in de treeview, de Spotweb database uitklap, en daarna "commentsxover", klapt de service er weer uit. Ik zie nog wel sub item "Columns", maar "Indexes" verwacht ik wel, maar komt dus niet. Na het opnieuw started van de service kan ik alle andere items wel gewoon uitklappen...

Wat je allicht kan proberen is oude posts er tussenuit gooien, dat scheelt een hele hoop in zowel snelheid als opslag op schijf. Daarna kan je kijken of dat geholpen heeft en zo ja, dan zou ik een retentie instellen voor een maximale leeftijd van spots binnen jouw Spotweb. Wat die value dan moet zijn, geen idee. Ik heb het zelf ook niet zo heel bijster hoog staan, omdat een boel toch middels DMCA verwijderd wordt.

[EgMaf]

CH40S schreef op maandag 01 augustus 2016 @ 18:33:
[...]
Wat je allicht kan proberen is oude posts er tussenuit gooien, dat scheelt een hele hoop in zowel snelheid als opslag op schijf. Daarna kan je kijken of dat geholpen heeft en zo ja, dan zou ik een retentie instellen voor een maximale leeftijd van spots binnen jouw Spotweb. Wat die value dan moet zijn, geen idee. Ik heb het zelf ook niet zo heel bijster hoog staan, omdat een boel toch middels DMCA verwijderd wordt.

Allereest bedankt voor je hulp zover!
Hoe kan ik de oude posts weggooien zonder de MySQL service te crashen? Ik heb retention days op 2000 gezet, maar geen idee hoe ik de DB kan opschonen.

[CH4OS]

Je kunt eens kijken als je een aantal (wel een paar 100 minimaal) verwijderd middels phpmyadmin, het meeste win je dan met de commentsxover tabel, weet even de naam niet exact meer, maar is de grootste tabel.

[mesa57]

Als je de retention verlaagt, bv naar 365 dagen, dan schoont spotweb de boel bij retrieve op.

[EgMaf]

Bedankt, maar als ik die tabel in phpMyAdmin probeer te openen, of als ik retrieve.php start, klapt de MySQL service er dus uit...

[mesa57]

Je database is gewoon corrupt. Schema verwijderen en overnieuw laden zou ik doen.

[EgMaf]

EgMaf schreef op maandag 01 augustus 2016 @ 00:14:
Nou, ik heb nu ook een probleem met mijn spotweb install.

Spotweb draait bij mij op een W10 client, met Apache, PHP 5.6.23 en MySQL via XAMPP, verder nogal simpele config. Het probleem is nu dat elke keer dat ik retrieve.php draai, de volgende melding komt en MySQL eruit klapt:

[...]


Als ik upgrade-db.php draai klapt MySQL er ook uit.
Een paar maanden geleden had ik iets vergelijkbaars, maar dat bleek te komen omdat ik PHP7.x gebruikte, en niet de ondersteunde 5.3+ (nu 5.6.23 dus). Dus daar kan het deze keer niet aan liggen.
Destijds heb ik alles opnieuw geinstalleerd, en het draaide nu weer lekker voor een paar maanden met een verse database.

Iemand enig idee wat het kan zijn, of in welke logfiles ik verder zou kunnen spitten?

Mezelf maar even gequote, want het probleem is weer terug ondanks de nieuwe DB

UPDATE: Laatste versie van MariaDB oven c:\XAMPP\mysql heel geinstalleerd, en de "kapotte" db werkt zelfs weer gewoon! XAMPP zou dus een nieuwere versie van MariaDB mee moeten leveren...

[ Voor 9% gewijzigd door EgMaf op 24-08-2016 15:29 ]

[Spockies]

Even een opmerking het zou prettig zijn als de uitleg hoe te installeren op windows wordt aangepast naar de huidige tijd aangezien deze nog duidelijk stamt uit 2011.
Dit zou prettig zijn voor beginners zoals ik, ben nu al een flinke tijd bezig en krijg het niet voor elkaar, terwijl het zo simpel lijkt.
Heb ik spotweb easy geprobeerd, maar daar krijg ik constant invaled xml file in couchpatao.
net nog clean install gevolgd vanaf de openingspost en heb nu een unable to conect to database error.
(ja heb database en user gedropt en opnieuw geprobeerd maar no go)
Dus als iemand een goede uitleg heeft graag zodat deze noob misschien het ook voor elkaar krijgt
mijn excuses als ik wat ruw overkom maar ben nu al een aantal weekenden bezig en krijg het maar niet voor elkaar

[MikeOO]

Spockies schreef op zaterdag 27 augustus 2016 @ 09:01:
Even een opmerking het zou prettig zijn als de uitleg hoe te installeren op windows wordt aangepast naar de huidige tijd aangezien deze nog duidelijk stamt uit 2011.
Dit zou prettig zijn voor beginners zoals ik, ben nu al een flinke tijd bezig en krijg het niet voor elkaar, terwijl het zo simpel lijkt.
Heb ik spotweb easy geprobeerd, maar daar krijg ik constant invaled xml file in couchpatao.
net nog clean install gevolgd vanaf de openingspost en heb nu een unable to conect to database error.
(ja heb database en user gedropt en opnieuw geprobeerd maar no go)
Dus als iemand een goede uitleg heeft graag zodat deze noob misschien het ook voor elkaar krijgt
mijn excuses als ik wat ruw overkom maar ben nu al een aantal weekenden bezig en krijg het maar niet voor elkaar

Dan zoek je even met Google en vind je een redelijk actueel stappenplan bij de makers van Spotweb
https://github.com/spotwe...eb-installeren-op-Windows

[Spockies]

Helaas dit is ook een zeer oude versieaangezien we inmiddels met xamp 2.5 werken en bij deze versie wordt de datbase niet ingelezen.
Het is de zelfde als de openingspost
Ik heb namelijk nog al veel fouten gehad zoals in mijn vorige post bescreven en heb dus inmiddels al zeer goed gezocht met Google enz.

[altern8]

Het schrijven van query's gaat mij niet zo zo af als dat ik zou willen. Heeft iemand misschien een query liggen die alle comment's verwijderd?

[Mr_Blobby]

altern8 schreef op woensdag 31 augustus 2016 @ 12:18:
Het schrijven van query's gaat mij niet zo zo af als dat ik zou willen. Heeft iemand misschien een query liggen die alle comment's verwijderd?

Verwijder alle opgehaalde comments:

SQL:

DELETE * FROM commentsfull

Verwijder alle verwijzingen naar comments; ook die nog niet zijn opgehaald:

SQL:

DELETE * FROM commentsxover

Zet all commentaar tellers op 0 bij elke spot:

SQL:

UPDATE spots
SET commentcount=0

[roeleboel]

Vraagje, ik raak er niet uit...
Verse installatie van spotweb (met apache 2) op bananapi, installatie-wizard doorlopen lukt, ik kan via /usr/bin/php retrieve.php ook spots binnenhalen, maar de webinterface wil niet opengaan...

Iemand enig idee wat er mis is?
(als er meer info nodig is: vraag gerust)

Relevante info:
apache 2.4
postgresql 9.4
installatiewizard is succesvol doorlopen
heb dit exacte probleem bij alle 3 de installatie-types (single user, public en <vergeten hoe die andere modus weer heet>)

Hij blokkeert meteen (bij laden van "<ip>/spotweb/" op deze fout:

code:

SpotWeb v0.67.28.31 on PHP v5.6.24-0+deb8u1 crashed
object(SqlErrorException)#15 (8) {
  ["message":protected]=>
  string(54) "22P02: 7: ERROR:  invalid input syntax for integer: """
  ["string":"CustomException":private]=>
  NULL
  ["code":protected]=>
  int(-1)
  ["file":protected]=>
  string(45) "/var/www/html/spotweb/lib/dbeng/dbeng_pdo.php"
  ["line":protected]=>
  int(59)
  ["trace":"Exception":private]=>
  array(5) {
    [0]=>
    array(6) {
      ["file"]=>
      string(45) "/var/www/html/spotweb/lib/dbeng/dbeng_pdo.php"
      ["line"]=>
      int(146)
      ["function"]=>
      string(4) "exec"
      ["class"]=>
      string(9) "dbeng_pdo"
      ["type"]=>
      string(2) "->"
      ["args"]=>
      array(2) {
        [0]=>
        string(270) "SELECT s.sessionid as sessionid,
                                s.userid as userid,
                                s.hitcount as hitcount,
                                s.lasthit as lasthit,
                                s.ipaddr as ipaddr,
                                s.devicetype as devicetype
                        FROM sessions AS s
                        WHERE (sessionid = :sessionid) AND (userid = :userid)"
        [1]=>
        array(2) {
          [":sessionid"]=>
          array(2) {
            [0]=>
            string(60) "wlsag4fn0e96yiclzili36ku3veubveuz1236ubf3950u1hjrj0q1h2gs8hy"
            [1]=>
            int(2)
          }
          [":userid"]=>
          array(2) {
            [0]=>
            string(0) ""
            [1]=>
            int(1)
          }
        }
      }
    }
    [1]=>
    array(6) {
      ["file"]=>
      string(55) "/var/www/html/spotweb/lib/dao/Base/Dao_Base_Session.php"
      ["line"]=>
      int(31)
      ["function"]=>
      string(10) "arrayQuery"
      ["class"]=>
      string(9) "dbeng_pdo"
      ["type"]=>
      string(2) "->"
      ["args"]=>
      array(2) {
        [0]=>
        string(270) "SELECT s.sessionid as sessionid,
                                s.userid as userid,
                                s.hitcount as hitcount,
                                s.lasthit as lasthit,
                                s.ipaddr as ipaddr,
                                s.devicetype as devicetype
                        FROM sessions AS s
                        WHERE (sessionid = :sessionid) AND (userid = :userid)"
        [1]=>
        array(2) {
          [":sessionid"]=>
          array(2) {
            [0]=>
            string(60) "wlsag4fn0e96yiclzili36ku3veubveuz1236ubf3950u1hjrj0q1h2gs8hy"
            [1]=>
            int(2)
          }
          [":userid"]=>
          array(2) {
            [0]=>
            string(0) ""
            [1]=>
            int(1)
          }
        }
      }
    }
    [2]=>
    array(6) {
      ["file"]=>
      string(72) "/var/www/html/spotweb/lib/services/User/Services_User_Authentication.php"
      ["line"]=>
      int(238)
      ["function"]=>
      string(10) "getSession"
      ["class"]=>
      string(16) "Dao_Base_Session"
      ["type"]=>
      string(2) "->"
      ["args"]=>
      array(2) {
        [0]=>
        string(60) "wlsag4fn0e96yiclzili36ku3veubveuz1236ubf3950u1hjrj0q1h2gs8hy"
        [1]=>
        string(0) ""
      }
    }
    [3]=>
    array(6) {
      ["file"]=>
      string(72) "/var/www/html/spotweb/lib/services/User/Services_User_Authentication.php"
      ["line"]=>
      int(110)
      ["function"]=>
      string(12) "validSession"
      ["class"]=>
      string(28) "Services_User_Authentication"
      ["type"]=>
      string(2) "->"
      ["args"]=>
      array(1) {
        [0]=>
        string(61) "wlsag4fn0e96yiclzili36ku3veubveuz1236ubf3950u1hjrj0q1h2gs8hy."
      }
    }
    [4]=>
    array(6) {
      ["file"]=>
      string(31) "/var/www/html/spotweb/index.php"
      ["line"]=>
      int(37)
      ["function"]=>
      string(17) "useOrStartSession"
      ["class"]=>
      string(28) "Services_User_Authentication"
      ["type"]=>
      string(2) "->"
      ["args"]=>
      array(1) {
        [0]=>
        bool(false)
      }
    }
  }
  ["previous":"Exception":private]=>
  NULL
  ["string":"Exception":private]=>
  string(0) ""
}
22P02: 7: ERROR:  invalid input syntax for integer: ""

[Neurd]

Sinds een week wil spotweb niet meer updaten. Dit is wat ik in de terminal krijg:


SpotWeb v0.67.28.31 on PHP v5.6.23 crashed

Fatal error occured retrieving reports:
HY000: 1206: The total number of locks exceeds the lock table size


#0 /volume1/web/spotweb/lib/dbeng/dbeng_pdo.php(74): dbeng_pdo->exec('DELETE FRO M com...', Array)
#1 /volume1/web/spotweb/lib/dao/Base/Dao_Base_Comment.php(279): dbeng_pdo->modif y('DELETE FROM com...', Array)
#2 /volume1/web/spotweb/retrieve.php(133): Dao_Base_Comment->expireCommentsFull( '1000')
#3 {main}

PHP Notice: Undefined variable: retriever in /volume1/web/spotweb/retrieve.php on line 313
PHP Fatal error: Call to a member function quit() on null in /volume1/web/spotw eb/retrieve.php on line 313


Voor mij is het abracadabra.
Het commando waarmee ik probeer te updaten is:
/usr/local/bin/php56 /volume1/web/spotweb/retrieve.php -force

EDIT: dit is wat ik zelf heb gevonden.
MySQL is trying to tell you that it doesn’t have enough room to store all of the row locks that it would need to execute your query

In phpadmin zie ik dat Commentsfull en Commentsxover veel ruimte in beslag nemen. Kan ik deze 2 dingen zomaar 'legen'?

[ Voor 8% gewijzigd door Neurd op 03-09-2016 23:49 ]

[elevator]

https://major.io/2010/01/...eeds-the-lock-table-size/ heb je dus al geprobeerd?

[roeleboel]

roeleboel schreef op donderdag 01 september 2016 @ 15:37:
Vraagje, ik raak er niet uit...
Verse installatie van spotweb (met apache 2) op bananapi, installatie-wizard doorlopen lukt, ik kan via /usr/bin/php retrieve.php ook spots binnenhalen, maar de webinterface wil niet opengaan...

Iemand enig idee wat er mis is?
(als er meer info nodig is: vraag gerust)

Relevante info:
apache 2.4
postgresql 9.4
installatiewizard is succesvol doorlopen
heb dit exacte probleem bij alle 3 de installatie-types (single user, public en <vergeten hoe die andere modus weer heet>)
<snip error code - zie boven>

Het werkt wel op een installatie met mysql, dus ergens zit een fout in het postgres-gedeelte van de installer, zal (wanneer ik tijd vind) een bugrapport inschieten op github.

[Cyleo]

Spotweb heb ik geinstalleerd en het werkt naar behoren, ik heb bij de installatie gekozen voor single user, wat mij destijds handig leek. Nu probeer ik echter spotweb te koppellen aan couchpotato etc en nzbhydra, en ik zie in de log files dat met name nzbhydra niet wil werken omdat deze blijft vragen op een api. Ik heb al wat in de config files lopen zoeken en op api-key in dit topic gezocht maar tot nu toe niets gevonden.

Is het mogelijk om van type installatie te wissellen of met single user installatie nog ergens een spotweb api key vandaan te toveren?

[mesa57]

Single user is prima. Bij je user gegevens staat de API key die je moet gebruiken.