SpotWeb - Webbased Spotnet - deel 2

[Staatslot]

quote:

mattblack85 schreef op zaterdag 5 mei 2018 @ 11:47:
Ik zag dat mijn spotweb geen spots meer binnen krijgt. Als ik handmatig via PowerShell de retrieve.php uitvoer krijg ik deze error, is daar iemand bekend mee:

SpotWeb v0.68.29.32 on PHP v5.6.31 crashed

Fatal error occured retrieving reports:
HY000: 1366: Incorrect string value: '\xF0\x9F\x93\x80 L...' for column 'title' at row 1


#0 C:\wamp64\www\spotweb\lib\dao\Base\Dao_Base_Spot.php(423): dbeng_pdo->batchInsert(Array, 'INSERT INTO spo...', Array,
Array)
#1 C:\wamp64\www\spotweb\lib\services\Retriever\Services_Retriever_Spots.php(612): Dao_Base_Spot->addSpots(Array, Array)
#2 C:\wamp64\www\spotweb\lib\services\Retriever\Services_Retriever_Base.php(227): Services_Retriever_Spots->process(Arra
y, '4749146', 4749957, 1525513231.6211)
#3 C:\wamp64\www\spotweb\lib\services\Retriever\Services_Retriever_Base.php(319): Services_Retriever_Base->loopTillEnd('
4749146', '1000')
#4 C:\wamp64\www\spotweb\retrieve.php(145): Services_Retriever_Base->perform()
#5 {main}

Finished retrieving spots.

Ik heb exact dezelfde error sinds een paar dagen.. ging er net naar kijken..
Ik wilde beginnen met een database check en repair.

[mattblack85]

quote:

Staatslot schreef op zaterdag 5 mei 2018 @ 12:13:
[...]


Ik heb exact dezelfde error sinds een paar dagen.. ging er net naar kijken..
Ik wilde beginnen met een database check en repair.

Dat zal ik ook proberen. Bij mij is het bijna 3 dagen dat de laatste spot werd binnen gehaald. Bij jou ook?

[Staatslot]

quote:

mattblack85 schreef op zaterdag 5 mei 2018 @ 15:35:
[...]


Dat zal ik ook proberen. Bij mij is het bijna 3 dagen dat de laatste spot werd binnen gehaald. Bij jou ook?

Ja, ik vermoed dat er een raar teken in de titel zit die onze database laat klappen maar heb er geen tijd meer in kunnen stoppen vandaag

[mesa57]

Je kunt 2 dingen doen om dit op te lossen :
1. Check de develop branch uit, daarin zit een oplossing
2. Zet retrieve full spots uit

[mattblack85]

quote:

mesa57 schreef op zondag 6 mei 2018 @ 10:46:
Je kunt 2 dingen doen om dit op te lossen :
1. Check de develop branch uit, daarin zit een oplossing
2. Zet retrieve full spots uit

Thanks! Ben even voor de makkelijke oplossing gegaan en full spots uitgezet

[mhoogendam]

Ik gebruik SpotWeb v0.67.28.31 / PHP v5.6.34 op een Synology NAS.

Ik krijg bij 1 specifieke spotter onderstaande melding:
code:

SpotWeb v0.67.28.31 on PHP v5.6.34 crashed String could not be parsed as XML

Hoe kan ik erachter komen welke string dit is en dit verhelpen?

[mesa57]

Ok, dat issue is opgelost in een redelijk recente versie van spotweb.
De syno package is (nog) niet geupdate hier mee. Wellicht kun je de code van github afhalen.

[mhoogendam]

quote:

mesa57 schreef op vrijdag 18 mei 2018 @ 13:59:
Ok, dat issue is opgelost in een redelijk recente versie van spotweb.
De syno package is (nog) niet geupdate hier mee. Wellicht kun je de code van github afhalen.

Is er een verwachte datum wanneer dat word geupdate?
Weet niet zo goed hoe ik direct via Github kan updaten

[mesa57]

Hangt van de package publisher af (nzbusenet).

[mesa57]

Package update heeft plaats gevonden.

[FreshMaker]

@mesa57
Bij de install kreeg ik een "foutmelding" over de naam.
Ik wilde dus een 'shared' system maken, maar na aanpassen van de namen werd de boel geinstalleerd als "public"
Is er een makkelijke manier om het om te zetten, of kan ik beter de boel opnieuw installeren ?

Voor mij niet meer nodig, ik had nog geen DB retrieve, dus de install nog eens doorlopen .. opgelost hier

FreshMaker wijzigde deze reactie 20-05-2018 13:52 (17%)

[Enforcer]

Is er een manier om het knopje "Inloggen" weer te laten werken als je in Spotweb heb aangegeven dat men als anonymous user (dus standaard) deze niet beschikbaar heeft ? Ik dacht namelijk dit knopje uit te willen schakelen en dat ik dan met een bepaalde url naar de loginpagina kon komen van Spotweb maar dat werkt dus niet.

Ik kan dus nu niet meer inloggen ... help ?

PS. https://<link_naar_spotweb>/spotweb/?page=login geeft nu aan "Toegang geweigerd voor [Log in (1::)] "

-edit-
Laat maar...
Command: php.exe upgrade-db.php --set-systemtype public

Enforcer wijzigde deze reactie 20-05-2018 22:07 (7%)

[mhoogendam]

quote:

mesa57 schreef op zaterdag 19 mei 2018 @ 12:25:
Package update heeft plaats gevonden.

Thanks! Ik had nog een oude repository erin staan dus heb nooit de updates meer gekregen.
Heb de update uitgevoerd, en lijkt weer te werken.
Nu weer nog koppeling maken met sabnzb en de manual retrieve knop terug zien te krijgen.

[gdl]

Ik krijg sinds kort de volgende melding bij het draaien van retrieve.php:

PHP Notice: Undefined offset: 4 in spotweb/vendor/pchart/class/pPie.class.php on line 1664

Iemand een idee hoe dit op te lossen?

[mesa57]

Laatste versie van spotweb installeren of statistieken bijwerken uitzetten.

[mdrop]

Was Spotweb nodig voor een tijdelijk project en wou het dit maal met een nieuwere PHP versie (in dit geval PHP 7.2) draaien dan het aanbevolen 5.*. Hiervoor zijn een aantal commando's anders dan de 'normale installatie' en dient er een extra repository toegevoegd te worden. Onderstaand de gebruikte commando's voor eventueel later gebruik en voor mensen die een nieuwe installatie van Spotweb willen starten;

Extra repository toevoegen, voor onder andere php7.2-fpm;
code:

sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y
sudo apt-get autoremove -y

Herstart de machine;
code:

sudo shutdown -r now

Installeer de benodigde applicaties;
code:

sudo apt-get install mysql-server php-mysql php-curl php-gd php-cli nginx openssl php7.2-fpm git zip php7.2-mbstring php-xml

Open het php.ini bestand,
code:

sudo nano /etc/php/7.2/fpm/php.ini

Verander een aantal zaken in geopende php.ini bestand,
code:

date.timezone = Europe/Amsterdam
memory_limit = 512M

Maak een nginx webserver config aan;
code:

sudo nano /etc/nginx/sites-available/spotweb

Gebruik de volgende waardes in de webserver config;
code:

server {
 listen 80;
 server_name sub.domein.nl, 192.168.1.110;
 root /var/www;
 index index.html index.htm index.php;

  location /spotweb {

        satisfy any;

        if ($uri !~ "api/"){
                rewrite /api/?$ /spotweb/index.php?page=newznabapi last;
        }
 location ~ \.php$ {
                try_files $uri =404;
                include fastcgi_params;
                fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
                fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
  }
 }
}

Verander de regel 'server_name sub.domein.nl, 192.168.1.110;' naar je eigen ip-reeks!

Activeer bovenstaande configuratie;
code:

sudo -i
unlink /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/spotweb /etc/nginx/sites-enabled/spotweb

Installeer (clone) de laatste Spotweb versie;
code:

git clone https://github.com/spotweb/spotweb /var/www/spotweb

Stel de juiste permissies in;
code:

chown -R www-data:www-data /var/www/spotweb

Maak de Spotweb database aan, verander het wachtwoord en de gebruiker;
code:

mysql -u root -p
CREATE USER spotwebgebruiker@localhost IDENTIFIED BY 'wachtwoord';
CREATE DATABASE spotwebdb;
GRANT ALL PRIVILEGES ON spotwebdb.* TO spotwebgebruiker@localhost IDENTIFIED BY 'wachtwoord';
FLUSH PRIVILEGES;

Herstart de machine om het geheel te starten;
code:

sudo shutdown -r now

Na de herstart kan de Spotweb configuratie beginnen, gebruik onderstaande URL;
code:

http://<ip adres>/spotweb/install.php

Bronnen:
https://mtgbhome.blogspot...web-on-bionic-beaver.html
https://gist.github.com/G...f770a3834d47274586d46ea62

[supernova]

SInds vandaag krijg ik de volgende melding als ik een upgrade-db uitvoer:

Database schema or settings upgrade failed:
HY000: 1553: Cannot drop index 'idx_commentsfull_1': needed in a foreign key constraint

en ook de volgende:

PHP Notice: Undefined index: column_name in /Library/WebServer/Documents/spotweb/lib/dbstruct/SpotStruct_abs.php on line 227
Dropping index idx_commentsfull_1

Heeft iemand een idee hoe ik dit kan oplossen, zonder de database opnieuw te moeten aanmaken en alle data kwijt ben.

[Meneer iCy]

Ik heb een nieuwe install uitgevoerd op een virtuele debian server, maar als ik de laatste versie van git haal (git clone https://github.com/spotweb/spotweb), maar in deze install zie ik na inloggen geen optie om de nzb handler te laten verwijzen naar nzbget. Enige optie die ik heb is Run SABnzbd trough users browser.

Wat ben ik vergeten te installeren/configureren? Ik zie het even niet meer helaas

[m-buurman]

icy schreef op woensdag 5 december 2018 @ 10:21:
Ik heb een nieuwe install uitgevoerd op een virtuele debian server, maar als ik de laatste versie van git haal (git clone https://github.com/spotweb/spotweb), maar in deze install zie ik na inloggen geen optie om de nzb handler te laten verwijzen naar nzbget. Enige optie die ik heb is Run SABnzbd trough users browser.

Wat ben ik vergeten te installeren/configureren? Ik zie het even niet meer helaas

Ik vermoed dat de rechten daarvoor niet zijn aangezet, config->user & groupmanagement -> grouplist -> group editen/aanmaken en dan daar 'Download manager integration NZBGet' toevoegen/allowen en deze vervolgens toekennen aan de juiste gebruikers.

[Meneer iCy]

m-buurman schreef op woensdag 5 december 2018 @ 10:56:
[...]


Ik vermoed dat de rechten daarvoor niet zijn aangezet, config->user & groupmanagement -> grouplist -> group editen/aanmaken en dan daar 'Download manager integration NZBGet' toevoegen/allowen en deze vervolgens toekennen aan de juiste gebruikers.

Klopt, had het al ondervonden. Schaam schaam.

Meneer iCy wijzigde deze reactie 05-12-2018 11:33 (20%)

[m-buurman]

icy schreef op woensdag 5 december 2018 @ 11:33:
[...]

Klopt, had het al ondervonden. Schaam schaam.

De sidepanel opent wanneer je rechtsbovenin op het sab knopje drukt, de nzb knopjes zijn er volgens mij alleen wanneer de connectie naar sab en/of nzbget werken. Lijkt er op dat daar iets niet goed zit.

Je had het gevonden begrijp ik

m-buurman wijzigde deze reactie 05-12-2018 11:39 (13%)

[Meneer iCy]

m-buurman schreef op woensdag 5 december 2018 @ 11:37:
[...]


De sidepanel opent wanneer je rechtsbovenin op het sab knopje drukt, de nzb knopjes zijn er volgens mij alleen wanneer de connectie naar sab en/of nzbget werken. Lijkt er op dat daar iets niet goed zit.

Je had het gevonden begrijp ik

Jup. had http er voor staan

[ge-flopt]

Iemand een idee hoe ik (simpel) opnieuw kan starten met het binnen halen van alle spots? Ik heb de retentie tijd verkeerd ingesteld. Of moet ik een bepaalde tabel leeggooien?

[pven]

ge-flopt schreef op woensdag 5 december 2018 @ 19:09:
Iemand een idee hoe ik (simpel) opnieuw kan starten met het binnen halen van alle spots? Ik heb de retentie tijd verkeerd ingesteld. Of moet ik een bepaalde tabel leeggooien?

Kan dat niet via settings / retention? Dat je dan het aantal dagen op 0, of misschien 1 zet. (Ik durf het zelf niet uit te proberen, sinds spot 1 heb ik volgens mij alles nog ... )

[alesandro_46]

@ge-flopt, wat @pven zegt klopt, bij Settings - Retrieve:

Retention on spots (in days). Older spots will be erased. Select 0 to keep all spots.

Ik weet niet zeker of hij dan alle oude spots binnen binnen haalt bij een retrieve, kan zijn dat je onderstaande ook nog moet doen:
settings - Newsserver de optie Buggy aanzetten.

Of als je het via de SSH doet:
/usr/share/spotweb/scripts/retrieve.sh --retro
(Je exacte locatie van retrieve.sh kan verschillen)

[ge-flopt]

Als ik de retentietijd aanpas van waarde X naar 0 haalt hij niet de oude spots opnieuw op.

--retro fixes the problem!

[nitrodesign]

Hallo Medetweakers,

Hierbij heb ik de volgende vraag, vandaag aan het stoeien geweest om via mijn NAS (DS414) Spotweb te laten draaien, dit functioneert naar behoren, alleen ik heb perongeluk de "filter" verwijderd. Mijn vraag nu is, hoe krijg ik die terug?

Heb al Gegoogled en krijg de volgende command die er voor moet zorgen dat de filter weer gereset wordt alleen deze werkt niet.
Deze command voer ik uit als root zijnde.

Command:
php upgrade-db.php --reset-filters

In de map:
volume1/web/spotweb

Op het moment als ik de commando uitvoer, krijg ik de volgende melding:

Could not open input file: upgrade-db.php

Als ik in de map kijk, zie ik ook niet de upgrade-db.php staan. Als ik verder navigeer naar de map /bin, dan zie ik het bestand wel staan. Op het moment als ik daar het commando doe, dan krijg ik de volgende melding:

PHP Fatal error: Undefined class constant 'MYSQL_ATTR_FOUND_ROWS' in /volume1/web/spotweb/lib/dbeng/dbeng_pdo_mysql.php on line 28

Fatal error: Undefined class constant 'MYSQL_ATTR_FOUND_ROWS' in /volume1/web/spotweb/lib/dbeng/dbeng_pdo_mysql.php on line 28

Weten jullie toevallig nog een oplossing? is het bijvoorbeeld mogelijk om de default filter terug te zetten, als iemand nog een default filter heeft, die wil downloaden zodat ik hem bij mij kan importeren?

Alvast bedankt voor de moeite.

[pven]

@nitrodesign kijk eens op https://www.synology-foru...-'mysql_attr_found_rows'/

Het lijkt alsof niet alle benodigde PHP-extensies aan staan.

[nitrodesign]

@pven Klopt het wel dat de "upgrade-db.php" wel in de andere map hoort te staan?

volume1/web/spotweb/bin

[pven]

nitrodesign schreef op zaterdag 29 december 2018 @ 20:03:
@pven Klopt het wel dat de "upgrade-db.php" wel in de andere map hoort te staan?

volume1/web/spotweb/bin

Mij staat bij dat dat bestand bij een van de releases verplaatst is.

[SchieveZot]

Ik heb zonet mijn db's van spotweb leeggemaakt en nu krijg ik volgende fout bij het uitvoeren van retrieve.php:

SpotWeb v0.68.29.32 on PHP v5.6.36 crashed

Fatal error occured retrieving reports:
Permission denied [21] for objectid []


#0 {main}

PHP Notice: Undefined variable: retriever in /volume1/web/spotweb/retrieve.php on line 304

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

Fatal error: Call to a member function quit() on null in /volume1/web/spotweb/retrieve.php on line 304

Iemand enig idee?

[Ryan_]

SchieveZot schreef op donderdag 3 januari 2019 @ 14:24:
Ik heb zonet mijn db's van spotweb leeggemaakt en nu krijg ik volgende fout bij het uitvoeren van retrieve.php:

SpotWeb v0.68.29.32 on PHP v5.6.36 crashed

Fatal error occured retrieving reports:
Permission denied [21] for objectid []


#0 {main}

PHP Notice: Undefined variable: retriever in /volume1/web/spotweb/retrieve.php on line 304

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

Fatal error: Call to a member function quit() on null in /volume1/web/spotweb/retrieve.php on line 304

Iemand enig idee?

Wat staat er op regeltje 304?

[SchieveZot]

Ryan_ schreef op donderdag 3 januari 2019 @ 14:26:
[...]


Wat staat er op regeltje 304?

moest blijkbaar in de taakplanner "sudo -i" toevoegen aan het script voor de retrieve uit te voeren...

Nu doet ie het wel

[daily.data.inj]

Gister aan de slag gegaan met Spotweb op mijn Syno NAS neer te zetten (inclusief gedoe met de PHP extensies). Nu denk ik dat het gelukt is. Als ik de retention period namelijk op 0 laat staan vult de Spotweb client zich met info dus dat lijkt mij goed.

Nu wil ik het volgende; alleen de spots ophalen van afgelopen x periode. Bijvoorbeeld van afgelopen half jaar ongeveer Dan duurt het uitvoeren van de retrieve.php ook een stuk korter. Kan dit?
Ik ben sinds gister aan het pielen maar ik kom niet verder. Als ik de retrieve.php via de CLI uitvoer staat er first message number 2, kan ik deze bijvoorbeeld nog beïnvloeden?

[jopie]

uitvoeren van retrieve duurt niet korter.
Laat retention op 1000 dagen staan en je hebt alleen de laatste 3 jaar in je archief.
Retrieve is dan alleen wat nieuw is sinds laatste retrieve.

[markheloking]

jagp schreef op vrijdag 22 april 2016 @ 16:00:
Een paar keer per week converteer ik de xml black-/whitelist van spotnet 1.8.5.x, zodat deze geschikt is voor spotweb.

Mocht je interesse hebben, dan kun je onderstaande URL's gebruiken in spotweb.

whitelist:

http://bit.ly/spotwebwhite

blacklist:

http://bit.ly/spotwebblack

Aangezien je gestopt bent dit te hosten, zou je dat script willen delen?

[pven]

markheloking schreef op vrijdag 8 februari 2019 @ 20:29:
[...]


Aangezien je gestopt bent dit te hosten, zou je dat script willen delen?

Ik heb niet het idee dat hij nog op Tweakers actief is.

[Henkske]

Beste allen,

Ik weet niet zeker of dit het juiste subforum is maar ik zit met het volgende:

Ubuntu 18.04
LAN: 192.168.0.1/24
Server (met nginx en spotweb): 192.168.0.221
Nginx root: /var/www/
Spotweb root: /var/www/spotweb/
Ik maak alleen gebruik van interne websites dus er is geen public domain. Wil alles bereiken met mijn openvpn die al draait.

Ik probeer momenteel nginx en spotweb op te zetten zodat het gebruik maakt van SSL.
Ik ben al zover dat de standaard pagina van NGINX automatisch naar HTTPS doorlinkt. Daarvoor gebruik ik de volgende config:

/etc/nginx/sites-enabled/default


code: filename

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    server_name 192.168.0.221
    root /var/www/
    index index.html index.htm index.nginx-debian.html;

    location / {
        try_files $uri $uri/ =404;
        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;
   }
}
server {
        listen 80;
        listen [::]:80;
        server_name 192.168.0.221;

        return 301 https://$server_name$request_uri;

        root /var/www/;

    location / {
        try_files $uri $uri/ =404;
        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;
   }
}

Ik dacht het mezelf makkelijk te maken en het volgende toe te voegen:

code: filename

server {
        listen 2233;
        listen [::]:2233;
        server_name 192.168.0.221; (# hier ook 192.168.0.221:2233 geprobeerd)

        return 301 https://$server_name$request_uri;

        root /var/www/spotweb;

    location / {
        try_files $uri $uri/ =404;
        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;
   }
}

Als ik een beetje speel met de settings dan krijg ik OF een 404, page not found of Error: "ssl_error_rx_record_too_long.

ik heb ook een file spotweb aangemaakt /etc/nginx/sites-enabled/spotweb en deze werkt gewoon goed echter zonder SSL.
Syntax:
code: filename

server{
listen 192.168.0.221:2233;
server_name 192.168.0.221;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
root /var/www/spotweb;
index index.html index.htm index.php;

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

    location ~ \.php$ {
            include /etc/nginx/fastcgi_params;
#            fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
            # The next two lines should go in your fastcgi_params
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Heeft iemand misschien een inzicht wat ik aan moet passen om spotweb en nginx over SSL te laten lopen? Alvast bedankt

[pven]

Ik heb net op mijn Linux-servertje een git pull gedaan om spotweb weer up-to-date te krijgen. Dat werkte best veel bij, zie https://pastebin.com/Uth44Vkc voor details (hierna heb ik upgrade-db.php nog gedraaid).

Hierna werken calls via de api nog wel, maar als ik in de web-interface een spot wil openen dan opent deze niet:

Error while loading this page, you will be returned automaticly to the mainview

Meer info kan ik niet vinden.

Iemand anders hier ook last van? Uiteraard kan ik een backup terugzetten, maar ik los het liever op.

pven wijzigde deze reactie 12-04-2019 14:51 (4%)

[Matis]

@pven de keren dat ik die foutmelding krijg is bij de volgende twee (of drie) scenario's:
- SpotWeb kan geen verbinding maken met de Usenet server.
- Je hebt te veel lijntjes open staan richting de Usenet server, waardoor de verbinding die SpotWeb probeert op te zetten actief geweigerd wordt.
- De spot die je aanklikt staat nog niet óf niet meer op de Usenet server.

Dat laatste punt kan komen doordat de headers wel zijn opgehaald, maar de inhoud nog niet. Of doordat de retentie instellingen van SpotWeb niet overeenkomt met die van jouw Usenet provider.

[pven]

Hm, hij is niet helemaal in orde:

code:

$ /usr/bin/php /blaat/spotweb/retrieve.php
PHP Parse error:  syntax error, unexpected '.', expecting ',' or ';' in /blaat/spotweb/lib/SpotDebug.php on line 17
$

@Matis Ik ken de foutmelding, maar na een paar keer klikken lost ie zichzelf meestal op. Mijn usenet-server was voor de update nog bereikbaar voor het retrieve-gebeuren. Het is een klein block-account welke ik alleen voor spotweb gebruik, te veel lijntjes kan dus eigenlijk niet. Het werkt voor geen enkele spot neer, het lijkt me stug dat alle spots weg zijn.

Werkt het met de laatste update bij jou nog wel?

Kleine update: ik heb de backup terug gezet, dan werkt het weer wel zoals het hoort. Ligt dus echt ergens aan een update. Ik heb ze nu heel even naast elkaar staan in verschillende directories maar met dezelfde database. Het is overduidelijk dat het door de update komt.

pven wijzigde deze reactie 12-04-2019 18:27 (17%)

[Matis]

@pven ikzelf heb de laatste versie van SpotWeb (nog) niet gedownload, maar jouw foutmelding leidt me naar een volgend issue: https://github.com/spotweb/spotweb/issues/408

Probeer dat eens...

[pven]

@Matis Het was even wat werk, maar uiteindelijk was php bijwerken naar 7.2 inderdaad de oplossing. Dank!

[Matis]

pven schreef op zaterdag 13 april 2019 @ 09:45:
@Matis Het was even wat werk, maar uiteindelijk was php bijwerken naar 7.2 inderdaad de oplossing. Dank!

Fijn dat het gelukt is. Daarom draai ik mijn websites en webservices het liefste in Docker. Dan kun je iedere applicatie zijn eigen versies en/of configuratie geven, zonder dat je de rest van het systeem "vervuilt".

[pven]

Matis schreef op zaterdag 13 april 2019 @ 10:49:
[...]

Fijn dat het gelukt is. Daarom draai ik mijn websites en webservices het liefste in Docker. Dan kun je iedere applicatie zijn eigen versies en/of configuratie geven, zonder dat je de rest van het systeem "vervuilt".

Op mijn Synology's lukt dat niet, en mijn el-cheapo-externe Linux-doosjes zijn daar helaas ook te zwak voor.

Maar goed: voor nu werkt het weer.

[Sennamph1938]

IK zie zoveel voorbij komen maar kan niet meer vinden.

ik wil spotweb op mijn synology DS918+ en dit heb ik allemaal geinstalleerd.
PHP 7.2 apache 2.4 en spotweb.

instellingen gaan goed maar update van spots niet.

welke code moet ik gebruiken ?
bij een krijg ik "mysql_attr_found_rows"foutmelding
en de andere "sqlstate[hy000} etc

[pven]

@Sennamph1938


code:

php retrieve.php

Heb je dat geprobeerd?

[Sennamph1938]

deze heb ik geprobeerd:

cd /volume1/web/spotweb/ && /usr/local/bin/php72 retrieve.php -force

en deze:

/usr/bin/php /volume1/web/spotweb/retrieve.php -force

[pven]

Als je je spotweb-site opent met iets als http://diskstation/spotweb/install.php , is dan alles in orde?

pven wijzigde deze reactie 09-05-2019 16:31 (10%)

[helm71]

Wordt spotweb eigenlijk nog maintained ? De jongste opmerking bij "spotweb updates" is drie jaar oud..

[pven]

helm71 schreef op zaterdag 11 mei 2019 @ 18:43:
Wordt spotweb eigenlijk nog maintained ? De jongste opmerking bij "spotweb updates" is drie jaar oud..

Volgens mij had ik niet zo heel lang geleden nog een update.

[Count_B]

Ik heb een Qnap en wil hierop Spotweb installeren. Ik heb op de QNAP de web en SQL server aangezet met de standaard waarden. Als ik nu via de appcenter naar qnapclub ga zie ik spotweb (1.3.9.0) staan en dit installeer ik dan. Als de installatie klaar is en ik open spotweb krijg ik de volgende melding:

Unable to connect to database:
No database settings have been entered, please use the 'install.php' wizard to install and configure Spotweb.
If you are upgrading from an earlier version of Spotweb, please consult https://github.com/spotwe...equently-asked-questions/ first

Moet ik eerst nog een database aanmaken of zou dat automatisch moeten gebeuren?

[mesa57]

De install.php vraagt toch om een database, gebruikersnaam en paswoord ?
Dus de database, gebruiker en paswoord moet je aanmaken.
De tabellen niet, dat doet de install.php
Overigens wordt dit in een volgende release opgelost, dan is dat niet meer nodig.
Dan is wel het root paswoord nodig, anders kan de install geen database en gebruiker aanmaken.

[nero355]

Count_B schreef op zaterdag 11 mei 2019 @ 23:38:
Moet ik eerst nog een database aanmaken of zou dat automatisch moeten gebeuren?

- https://github.com/spotwe...Pangolin%29-%28english%29
- https://www.htpcguides.co...-personal-usenet-indexer/
- enz. enz...

Alles staat op GitHub, maar je moet gewoon zelf effe de juiste stukjes bij elkaar zoeken

Onlangs als test wat ermee zitten klooien op een Raspberry Pi, voordat ik het geheel in een VM ga gooien en eigenlijk was het best wel snel opgezet!

[mrwolf]

Op mijn Synology werkt Spotweb niet meer, ik vermoed na de laatste DSM update.

Unable to connect to database:
SQLSTATE[HY000] [1045] Access denied for user 'spotweb'@'localhost' (using password: YES)


Please make sure your database server is up and running and your connection parameters are set

Ik heb in PhpMyAdmin de user spotweb gecheckt, verwijderd en opnieuw aangemaakt. Deze heeft ALL PRIVILEGES. Ook bij het opnieuw installeren loopt het vast op de databaseconnectie:

SQLSTATE[HY000] [1045] Access denied for user 'spotweb'@'localhost' (using password: YES)

Waar kan ik dit fixen?


edit: ongeduldig, dus hele database weggekiept en opnieuw begonnen

mrwolf wijzigde deze reactie 17-05-2019 20:42 (6%)

[pven]

Na een update van mijn Synology zie ik het onderstaande als ik spotweb open (deze melding staat tientallen keren op het scherm):

Warning: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /volume1/web/spotweb/lib/SpotTemplateHelper.php on line 862 

Iemand een idee hoe ik dat kan fixen? Het ligt vast ergens in mijn Synology, maar ik heb geen idee waar ik dit moet zoeken. (Google geeft me ook weinig hints.)

[nero355]

@pven : Dat is gewoon de timezone setting van PHP of MySQL

- https://dev.mysql.com/doc...en/time-zone-support.html
- https://www.php.net/manual/en/timezones.php

Beiden kan je als het goed is op Europe/Amsterdam zetten...

[Sa1]

Heb sinds 2 dagen een probleempje. Volgens mij is er niets gewijzigd, maar goed, er zal wel 'iets' veranderd zijn. Ik heb een scheduled task in m'n synology, die automatisch retrieve.php aftrapt.

Doet eigenlijk geen gekke dingen anders dan het aftrappen van het commando, het ziet er als volgt uit:

code:

cd /volume1/web/spotweb/
sudo /usr/local/bin/php56 /volume1/web/spotweb/retrieve.php --force

Ik had dus al 2 dagen geen updates meer, dus ik in de log kijken kom ik het volgende tegen:

code:

Unable to connect to database: SQLSTATE[HY000] [2002] No such file or directory

Dat is even schrikken natuurlijk, maar de site doet het prima dus de DB koppeling is er gewoon nog. Ook even naar de dbsettings gekeken, juiste gegevens en met die gegevens kan ik via MySQL ook gewoon aanmelden bij de DB.

Nu als ik druk op 'retrieve' op de site zelf, dan doet ie het dus ook gewoon. Dus alleen van commandline af doet ie het niet.

Via SSH aftrappen van 't commando lukt dus ook niet, krijg ik dezelfde foutmelding. Nu zie ik wel dat de retrieve knop op de site een APIKEY mee stuurt, maar daar kan het toch niets mee te maken hebben? 't Heeft het altijd gewoon vlekkenloos gedaan.

ps, kom wel veel dezelfde melding ook in dit forum tegen, maar niet echt een oplossing, iemand die al gevonden?

Sa1 wijzigde deze reactie 06-06-2019 10:38 (4%)

[mesa57]

Is enkele dagen geleden je syno geüpdate ?
Welke versie van php wordt via webstation gebruikt, die kan namelijk afwijken van php 5.6 (welke eigenlijk al niet meer gesupport wordt) ?

[Peter is Gamer]

Ik heb exact het zelfde probleem, een oplossing heb ik helaas nog niet.

Het volledig verwijderen en opnieuw aanmaken is in ieder geval niet de oplossing (voor mij)

Ik draai de volgende versies:
Webstation 2.1.7.-0147
HTTP backend: Apache HTTP Server 2.2
PHP versie: php5.6

Sa1 schreef op donderdag 6 juni 2019 @ 10:36:
Heb sinds 2 dagen een probleempje. Volgens mij is er niets gewijzigd, maar goed, er zal wel 'iets' veranderd zijn. Ik heb een scheduled task in m'n synology, die automatisch retrieve.php aftrapt.

Doet eigenlijk geen gekke dingen anders dan het aftrappen van het commando, het ziet er als volgt uit:

code:

cd /volume1/web/spotweb/
sudo /usr/local/bin/php56 /volume1/web/spotweb/retrieve.php --force

Ik had dus al 2 dagen geen updates meer, dus ik in de log kijken kom ik het volgende tegen:

code:

Unable to connect to database: SQLSTATE[HY000] [2002] No such file or directory

Dat is even schrikken natuurlijk, maar de site doet het prima dus de DB koppeling is er gewoon nog. Ook even naar de dbsettings gekeken, juiste gegevens en met die gegevens kan ik via MySQL ook gewoon aanmelden bij de DB.

Nu als ik druk op 'retrieve' op de site zelf, dan doet ie het dus ook gewoon. Dus alleen van commandline af doet ie het niet.

Via SSH aftrappen van 't commando lukt dus ook niet, krijg ik dezelfde foutmelding. Nu zie ik wel dat de retrieve knop op de site een APIKEY mee stuurt, maar daar kan het toch niets mee te maken hebben? 't Heeft het altijd gewoon vlekkenloos gedaan.

ps, kom wel veel dezelfde melding ook in dit forum tegen, maar niet echt een oplossing, iemand die al gevonden?

Peter is Gamer wijzigde deze reactie 07-06-2019 09:46 (3%)

[AuroraNL]

Zelfde probleem hier, lijkt gekomen na een update van PHP56. Ik ben nu overgeschakeld naar PHP70 (in webstation samen met Nginx). Na de wizzard van spotweb opnieuw te doorlopen kreeg ik bij retrieve een foutmelding, die is opgelost door handmatig /usr/local/etc/php70/conf.d/webstation-extensions.ini aan te maken met de volgende content:

extension = bcmath.so
extension = bz2.so
extension = curl.so
extension = gd.so
extension = gettext.so
extension = openssl.so
extension = pdo_mysql.so
extension = zip.so

retrieve vanaf de CLI werkt weer, vergeet niet je cronjob aan te passen naar PHP70

[Sa1]

Peter is Gamer schreef op vrijdag 7 juni 2019 @ 09:42:
Ik heb exact het zelfde probleem, een oplossing heb ik helaas nog niet.

Het volledig verwijderen en opnieuw aanmaken is in ieder geval niet de oplossing (voor mij)

Ik draai de volgende versies:
Webstation 2.1.7.-0147
HTTP backend: Apache HTTP Server 2.2
PHP versie: php5.6


[...]

Ik gebruik exact dezelfde versies. K ga eens kijken of de upgrade inderdaad voor mij hetgeen ook oplost.

Okay, heb de boel omgezet en werkt. Wel is het inderdaad noodzakelijk om die .ini aan te maken zoals AuroraNL aangeeft, anders doet de retrieve.php via de commandline het nog steeds niet. De website deed het wel direct, ik hoefde achteraf denk ik niet install.php te draaien.

Super, heel fijn, tnx!

Sa1 wijzigde deze reactie 07-06-2019 11:46 (22%)

[Sa1]

Goed, volgende probleem. Zal hier zeker aan gerelateerd zijn. Als ik nu een NZB push naar SabNZB, wat uiteraard altijd gefunctioneerd heeft geeft nu een foutmelding in SabNZB.

code:

Invalid NZB file LinuxDistro.nzb, skipping (reason=syntax error, line=2)

Kan dat te maken hebben dat die nog op PHP56 draait ofzo?

Als ik een NZB zelf download, dan staat het volgende in de eerste paar lines:

code:

Warning: fileperms(): stat failed for /volume1/web/spotweb/lib/../cache/nzb/56 in /volume1/web/spotweb/lib/dao/Base/Dao_Base_Cache.php on line 293

Warning: fileowner(): stat failed for /volume1/web/spotweb/lib/../cache/nzb/56 in /volume1/web/spotweb/lib/dao/Base/Dao_Base_Cache.php on line 294

Warning: filegroup(): stat failed for /volume1/web/spotweb/lib/../cache/nzb/56 in /volume1/web/spotweb/lib/dao/Base/Dao_Base_Cache.php on line 295

Lijkt me niet goed, toch? Die 56 zal refereren naar PHP versie.

M'n vermoeden klopt wel. Als ik die NZB incl deze 3 lines upload naar SAB, dan zegt hij hetzelfde. Haal ik de 3 lines weg, dan start hij direct met downloaden. Iets in spotweb genereert dit dus, maar wat.

Edit:

En opgelost.

code:

php70 ./bin/check-cache.php

Nu lijkt alles weer keurig te werken.

Sa1 wijzigde deze reactie 07-06-2019 12:57 (62%)

[Ringgss]

Bij testen van configuratie krijg ik de volgende foutmelding

Include(/opt/lampp/htdocs/spotweb/vendor/composer/../../lib/dao/Mysql/Dao_Mysql_Factory.php): failed to open stream: No such file or directoryinclude(): Failed opening '/opt/lampp/htdocs/spotweb/vendor/composer/../../lib/dao/Mysql/Dao_Mysql_Factory.php' for inclusion (include_path='.:/opt/lampp/lib/php')
Fatal error: Uncaught Error: Class 'Dao_Mysql_Factory' not found in /opt/lampp/htdocs/spotweb/lib/dao/Dao_Factory.php:118 Stack trace: #0 /opt/lampp/htdocs/spotweb/lib/SpotInstall.php(287): Dao_Factory::getDAOFactory('pdo_mysql') #1 /opt/lampp/htdocs/spotweb/install.php(71): SpotInstall::askSpotwebSettings() #2 {main} thrown in /opt/lampp/htdocs/spotweb/lib/dao/Dao_Factory.php on line 118

config:
Ubuntu 18.04
Xampp

Ringgss wijzigde deze reactie 10-06-2019 10:52 (0%)
Reden: Typo

[Sa1]

En je vraag is?

[duiveltje666]

Peter is Gamer schreef op vrijdag 7 juni 2019 @ 09:42:
Ik heb exact het zelfde probleem, een oplossing heb ik helaas nog niet.

Het volledig verwijderen en opnieuw aanmaken is in ieder geval niet de oplossing (voor mij)

Ik draai de volgende versies:
Webstation 2.1.7.-0147
HTTP backend: Apache HTTP Server 2.2
PHP versie: php5.6


[...]

Please note the 2.2.x branch has now passed the end of life at the Apache HTTP Server project and no further activity will occur including security patches. Users must promptly complete their transitions to this 2.4.x release of httpd to benefit from further bug fixes or new features.
Perhaps es upgraden ?

[Ringgss]

Sa1 schreef op zondag 9 juni 2019 @ 22:43:
En je vraag is?

Iemand enig idee wat er fout gaat?

Update: Heb het werkend, na nieuwe pull van git

Ringgss wijzigde deze reactie 10-06-2019 19:51 (13%)

[mrwolf]

Peter is Gamer schreef op vrijdag 7 juni 2019 @ 09:42:
Ik heb exact het zelfde probleem, een oplossing heb ik helaas nog niet.

Het volledig verwijderen en opnieuw aanmaken is in ieder geval niet de oplossing (voor mij)

Ik draai de volgende versies:
Webstation 2.1.7.-0147
HTTP backend: Apache HTTP Server 2.2
PHP versie: php5.6


[...]

Drie dagen gezocht naar een oplossing, en gevonden!

[Slowmotion]

Thanks, wel een oplossing waar je op moet komen..

[Sangroid]

@mrwolf Thanks, prima oplossing, ik had het zoeken al wat eerder opgegeven...

[d-vine]

Door de laatste problemen met spotweb wat ik opgelost kreeg (poortnummer bij localhost) dacht ik laat ik spotweb net als mijn wordpress overzetten op php72. Alles draait op mijn synology DS716

Nu draait alles goed en ik kan via putty alles keer op keer binnenhalen. Echter via taakplanner van mijn synology komt er een fout melding acces denied
Deze werkte altijd bij php56 en dezelfde command line heb ik aangepast naar php72.
In putty werkt deze command line maar synology niet.
ik heb op advies al keer sudo -i bij command gezet maar dat mocht niet baten.


/usr/local/bin/php72 /volume1/web/spotweb/retrieve.php



de taakplanner met user root ingesteld

-- foutmelding via mail --
foutmelding via mail
Taak: Spotweb retrive
Starttijd: Thu, 27 Jun 2019 11:38:23 GMT
Stoptijd: Thu, 27 Jun 2019 11:38:23 GMT
Huidige status: 255 (Onderbroken)
Standaard uitvoer/fout:


SpotWeb v0.68.29.32 on PHP v7.2.13 crashed

Fatal error occured retrieving reports:
Permission denied [21] for objectid []


#0 {main}

PHP Notice: Undefined variable: retriever in /volume1/web/spotweb/retrieve.php on line 304

Notice: Undefined variable: retriever in /volume1/web/spotweb/retrieve.php on line 304
PHP Fatal error: Uncaught Error: Call to a member function quit() on null in /volume1/web/spotweb/retrieve.php:304
Stack trace:
#0 {main}
thrown in /volume1/web/spotweb/retrieve.php on line 304

Fatal error: Uncaught Error: Call to a member function quit() on null in /volume1/web/spotweb/retrieve.php:304
Stack trace:
#0 {main}
thrown in /volume1/web/spotweb/retrieve.php on line 304

---------------------------------------------------------------------------------------------------------------------------------

Omdat het met putty wel werkt en ik de toegang foutmelding krijg in synology terwijl ik niets met de rechten heb gedaan na aanpassen php56 naar php72 ben ik een beetje het spoor bijster.

EDIT:
opgelost
Ik heb met puty de root rechten nog een keer doorgevoerd op de map en files.
Het werkte niet met handmatig uitvoeren ik was er even klaar mee maar vanmorgen kreeg ik ineens een mail dat mijn spots zijn binnengehaald. Ik juich nog niet te vroeg maar hoop dat dit het was.
blijft raar dat het handmatig uitvoeren een fout gaf en nu met dat geplande tijd van de taak het goed gaat

d-vine wijzigde deze reactie 01-07-2019 09:34 (9%)

[Sa1]

Sinds m'n upgrade naar PHP70 heb ik een vervelend terugkomend probleem. Als ik een NZB doorstuur naar SabNZB dan vindt hij hem fout. Dat klopt ook want als je hem handmatig download (de nzb) dan staan er regels in als volgt:
code:

Warning: fileperms(): stat failed for /volume1/web/spotweb/lib/../cache/nzb/64 in /volume1/web/spotweb/lib/dao/Base/Dao_Base_Cache.php on line 293

Warning: fileowner(): stat failed for /volume1/web/spotweb/lib/../cache/nzb/64 in /volume1/web/spotweb/lib/dao/Base/Dao_Base_Cache.php on line 294

Warning: filegroup(): stat failed for /volume1/web/spotweb/lib/../cache/nzb/64 in /volume1/web/spotweb/lib/dao/Base/Dao_Base_Cache.php on line 295

Als ik handmatig deze regels weghaal, en upload naar Sab dan werkt het gewoon.

Ik kan deze regels wegkrijgen door de cache te checken ( php70 ./check-cache.php). Maar dit lijkt niet altijd te werken.

Heeft iemand dit wel is gehad? Of hier een oplossing voor of een idee waar dit vandaan komt?

[thejoker80]

een klein vraagje. Ik heb handmatig de retrieve uitgevoerd maar hij laadt alleen spots van voor 2009..... iemand enig idee. Ik zag wel dat in de settings de retentie op 50 dagen staat maar de datum vanaf stond nog op de allereerste datum, 1-1-2007 geloof ik.

Ik heb de retrieve gisterochtend gestart en vanochtend was hij niks verder dan gistermiddag. Als ik de retrieve echter opnieuw probeer uit te voeren zegt hij dat er al een proces loopt.

moet ik eerst een nieuwe retrieve forcen? (of moet ik daarvoor de database is weggooien? Ik heb de database overigens niet op shared staan, kan dat kwaad?)

[Sa1]

thejoker80 schreef op maandag 8 juli 2019 @ 11:27:
een klein vraagje. Ik heb handmatig de retrieve uitgevoerd maar hij laadt alleen spots van voor 2009..... iemand enig idee. Ik zag wel dat in de settings de retentie op 50 dagen staat maar de datum vanaf stond nog op de allereerste datum, 1-1-2007 geloof ik.

Ik heb de retrieve gisterochtend gestart en vanochtend was hij niks verder dan gistermiddag. Als ik de retrieve echter opnieuw probeer uit te voeren zegt hij dat er al een proces loopt.

moet ik eerst een nieuwe retrieve forcen? (of moet ik daarvoor de database is weggooien? Ik heb de database overigens niet op shared staan, kan dat kwaad?)

Je kunt hem nog een x starten met de optie --force, start je hem overigens van de commandline? Denk het haast niet.

[thejoker80]

Sa1 schreef op maandag 8 juli 2019 @ 11:54:
[...]
Je kunt hem nog een x starten met de optie --force, start je hem overigens van de commandline? Denk het haast niet.

ga ik doen, via putty.

[Tomba]

3 dagen geleden heb ik (met Git) mijn spotweb bijgewerkt, de upgrade-db.php gerund en sindsdien haalt de retriever geen nieuwe spots meer op. Als ik m handmatig run krijg ik de melding dat retriever.php al loopt. Als ik --force toevoeg krijg ik deze melding:

code:

php /var/www/spotweb/spotweb/retrieve.php --force
Last retrieve at Wed 31 Jul 2019 11:30:51 AM CEST
Retrieving new Spots from server news.newshosting.com...
Appr. Message count:    3285102
First message number:   2
Last message number:    3285104
Current article number: 3284025

Retrieving 3284025 till 3285105 (parsed: 1080, in DB: 0, signed: 998, invalid: 23, rtntn.skip: 0, mod: 59, full: 0, total: 1080)Programming error for: INSERT INTO spots(messageid, poster, title, tag, category, subcata,
                                                                                                                subcatb, subcatc, subcatd, subcatz, stamp, reversestamp, filesize, spotterid)
                                                                        VALUES

De table zelf lijkt mij in orde:

code:

mysql> show columns from spots;
+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| id           | int(11)             | NO   | PRI | NULL    | auto_increment |
| messageid    | varchar(128)        | NO   | UNI |         |                |
| poster       | varchar(128)        | YES  | MUL | NULL    |                |
| title        | varchar(128)        | YES  | MUL | NULL    |                |
| tag          | varchar(128)        | YES  | MUL | NULL    |                |
| category     | int(11)             | YES  | MUL | NULL    |                |
| subcata      | varchar(64)         | YES  |     | NULL    |                |
| subcatb      | varchar(64)         | YES  |     | NULL    |                |
| subcatc      | varchar(64)         | YES  |     | NULL    |                |
| subcatd      | varchar(64)         | YES  |     | NULL    |                |
| subcatz      | varchar(64)         | YES  |     | NULL    |                |
| stamp        | int(10) unsigned    | YES  | MUL | NULL    |                |
| reversestamp | int(11)             | YES  | MUL | 0       |                |
| filesize     | bigint(20) unsigned | NO   |     | 0       |                |
| moderated    | tinyint(1)          | YES  |     | NULL    |                |
| commentcount | int(11)             | YES  |     | 0       |                |
| spotrating   | int(11)             | YES  |     | 0       |                |
| reportcount  | int(11)             | YES  |     | 0       |                |
| spotterid    | varchar(32)         | YES  | MUL | NULL    |                |
| editstamp    | int(10) unsigned    | YES  |     | NULL    |                |
| editor       | varchar(128)        | YES  |     | NULL    |                |
+--------------+---------------------+------+-----+---------+----------------+
21 rows in set (0.00 sec)

Het nogmaals runnen van upgrade-db.php geeft een crash:

code:

php /var/www/spotweb/spotweb/bin/upgrade-db.php
Updating schema..(pdo_mysql)
        Validating spots(messageid)
        Validating spots(poster)
        Validating spots(title)
        Validating spots(tag)
        Validating spots(category)
        Validating spots(subcata)
        Validating spots(subcatb)
        Validating spots(subcatc)
        Validating spots(subcatd)
        Validating spots(subcatz)
        Validating spots(stamp)
                Modifying column stamp (type) on spots
        Validating spots(reversestamp)
        Validating spots(filesize)
                Modifying column filesize (type) on spots


SpotWeb crashed

Database schema or settings upgrade failed:
   42000: 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'BIGINTEGER UNSIGNED  DEFAULT 0 NOT NULL' at line 1


#0 /var/www/spotweb/spotweb/lib/dbstruct/SpotStruct_mysql.php(223): dbeng_pdo->rawExec('ALTER TABLE spo...')
#1 /var/www/spotweb/spotweb/lib/dbstruct/SpotStruct_abs.php(161): SpotStruct_mysql->modifyColumn('filesize', 'spots', 'BIGINTEGER UNSI...', 'DEFAULT 0', true, '', 'type')
#2 /var/www/spotweb/spotweb/lib/dbstruct/SpotStruct_abs.php(356): SpotStruct_abs->validateColumn('filesize', 'spots', 'BIGINTEGER UNSI...', '0', true, '')
#3 /var/www/spotweb/spotweb/lib/services/Upgrade/Services_Upgrade_Base.php(42): SpotStruct_abs->updateSchema()
#4 /var/www/spotweb/spotweb/bin/upgrade-db.php(34): Services_Upgrade_Base->database()

Iemand enig idee hoe ik dit zou kunnen fixen? Systeem draait op Ubuntu 18.04 (met alle updates)

Tomba wijzigde deze reactie 03-08-2019 11:05 (67%)

[Tomba]

Tomba schreef op zaterdag 3 augustus 2019 @ 11:01:
3 dagen geleden heb ik (met Git) mijn spotweb bijgewerkt, de upgrade-db.php gerund en sindsdien haalt de retriever geen nieuwe spots meer op. Als ik m handmatig run krijg ik de melding dat retriever.php al loopt. Als ik --force toevoeg krijg ik deze melding:

code:

php /var/www/spotweb/spotweb/retrieve.php --force
Last retrieve at Wed 31 Jul 2019 11:30:51 AM CEST
Retrieving new Spots from server news.newshosting.com...
Appr. Message count:    3285102
First message number:   2
Last message number:    3285104
Current article number: 3284025

Retrieving 3284025 till 3285105 (parsed: 1080, in DB: 0, signed: 998, invalid: 23, rtntn.skip: 0, mod: 59, full: 0, total: 1080)Programming error for: INSERT INTO spots(messageid, poster, title, tag, category, subcata,
                                                                                                                subcatb, subcatc, subcatd, subcatz, stamp, reversestamp, filesize, spotterid)
                                                                        VALUES

De table zelf lijkt mij in orde:

code:

mysql> show columns from spots;
+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| id           | int(11)             | NO   | PRI | NULL    | auto_increment |
| messageid    | varchar(128)        | NO   | UNI |         |                |
| poster       | varchar(128)        | YES  | MUL | NULL    |                |
| title        | varchar(128)        | YES  | MUL | NULL    |                |
| tag          | varchar(128)        | YES  | MUL | NULL    |                |
| category     | int(11)             | YES  | MUL | NULL    |                |
| subcata      | varchar(64)         | YES  |     | NULL    |                |
| subcatb      | varchar(64)         | YES  |     | NULL    |                |
| subcatc      | varchar(64)         | YES  |     | NULL    |                |
| subcatd      | varchar(64)         | YES  |     | NULL    |                |
| subcatz      | varchar(64)         | YES  |     | NULL    |                |
| stamp        | int(10) unsigned    | YES  | MUL | NULL    |                |
| reversestamp | int(11)             | YES  | MUL | 0       |                |
| filesize     | bigint(20) unsigned | NO   |     | 0       |                |
| moderated    | tinyint(1)          | YES  |     | NULL    |                |
| commentcount | int(11)             | YES  |     | 0       |                |
| spotrating   | int(11)             | YES  |     | 0       |                |
| reportcount  | int(11)             | YES  |     | 0       |                |
| spotterid    | varchar(32)         | YES  | MUL | NULL    |                |
| editstamp    | int(10) unsigned    | YES  |     | NULL    |                |
| editor       | varchar(128)        | YES  |     | NULL    |                |
+--------------+---------------------+------+-----+---------+----------------+
21 rows in set (0.00 sec)

Het nogmaals runnen van upgrade-db.php geeft een crash:

code:

php /var/www/spotweb/spotweb/bin/upgrade-db.php
Updating schema..(pdo_mysql)
        Validating spots(messageid)
        Validating spots(poster)
        Validating spots(title)
        Validating spots(tag)
        Validating spots(category)
        Validating spots(subcata)
        Validating spots(subcatb)
        Validating spots(subcatc)
        Validating spots(subcatd)
        Validating spots(subcatz)
        Validating spots(stamp)
                Modifying column stamp (type) on spots
        Validating spots(reversestamp)
        Validating spots(filesize)
                Modifying column filesize (type) on spots


SpotWeb crashed

Database schema or settings upgrade failed:
   42000: 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'BIGINTEGER UNSIGNED  DEFAULT 0 NOT NULL' at line 1


#0 /var/www/spotweb/spotweb/lib/dbstruct/SpotStruct_mysql.php(223): dbeng_pdo->rawExec('ALTER TABLE spo...')
#1 /var/www/spotweb/spotweb/lib/dbstruct/SpotStruct_abs.php(161): SpotStruct_mysql->modifyColumn('filesize', 'spots', 'BIGINTEGER UNSI...', 'DEFAULT 0', true, '', 'type')
#2 /var/www/spotweb/spotweb/lib/dbstruct/SpotStruct_abs.php(356): SpotStruct_abs->validateColumn('filesize', 'spots', 'BIGINTEGER UNSI...', '0', true, '')
#3 /var/www/spotweb/spotweb/lib/services/Upgrade/Services_Upgrade_Base.php(42): SpotStruct_abs->updateSchema()
#4 /var/www/spotweb/spotweb/bin/upgrade-db.php(34): Services_Upgrade_Base->database()

Iemand enig idee hoe ik dit zou kunnen fixen? Systeem draait op Ubuntu 18.04 (met alle updates)

Niemand een idee? Heb niet zo'n zin om heel Spotweb opnieuw te installeren

[nero355]

Tomba schreef op zondag 4 augustus 2019 @ 13:38:
Niemand een idee? Heb niet zo'n zin om heel Spotweb opnieuw te installeren

Zeker ook geen backups gemaakt ?!

Maar ehh... waarom probeer je niet te achterhalen op welk PID dat script loopt VOORDAT je opties als -force gaat proberen

Ik zou zeggen doe dat nu alsnog en kijk hoe ver je komt

[Tomba]

nero355 schreef op zondag 4 augustus 2019 @ 14:49:
[...]

Zeker ook geen backups gemaakt ?!

Nee geen backup gemaakt, tot op heden ook nog nooit nodig gehad d'oh.

nero355 schreef op zondag 4 augustus 2019 @ 14:49:
[...]
Maar ehh... waarom probeer je niet te achterhalen op welk PID dat script loopt VOORDAT je opties als -force gaat proberen

Aangezien

code:

ps ax | grep php

geen PID terug gaf leek het me aannemelijk dat het script niet liep, vandaar dat ik --force geprobeerd heb.

NB de foutmelding die ik hierboven post staat vanaf de git pull in de logfile, issue is dus direct na upgrade ontstaan.

nero355 schreef op zondag 4 augustus 2019 @ 14:49:
[...]
Ik zou zeggen doe dat nu alsnog en kijk hoe ver je komt

Geen stap verder natuurlijk Error blijft hetzelfde, heb in crontab de scheduled task uitgeschakeld en server gereboot. Daarna wil retrieve.php eenmalig runnen zonder --force om er dus mee te kappen...

Gezien het feit dat niemand verder reageert loop ik ogenschijnlijk tegen een volledig onbekend Spotweb issue aan Zit niets anders op dan een rebuild vrees ik

[pven]

@Tomba Heb je geprobeerd om via git naar een vorige release terug te gaan? Met wat geluk heb dan weer iets werkends.

[Tomba]

pven schreef op dinsdag 6 augustus 2019 @ 08:11:
@Tomba Heb je geprobeerd om via git naar een vorige release terug te gaan? Met wat geluk heb dan weer iets werkends.

Yes en ook een compleet nieuwe git pull, maar probleem blijft. Issue moet dus wel aan de database kant zitten, vrees dat t dus kwestie wordt van alle spots opnieuw binnen halen....

[alesandro_46]

Tomba schreef op dinsdag 6 augustus 2019 @ 08:29:
[...]

Yes en ook een compleet nieuwe git pull, maar probleem blijft. Issue moet dus wel aan de database kant zitten, vrees dat t dus kwestie wordt van alle spots opnieuw binnen halen....

Misschien is het een optie om een tijdelijke database aan te maken, de gegevens daarvan in te vullen in de 'dbsettings.inc.php' en kijken of de retrieve dan wel verder gaat?

[Tomba]

alesandro_46 schreef op dinsdag 6 augustus 2019 @ 08:38:
[...]

Misschien is het een optie om een tijdelijke database aan te maken, de gegevens daarvan in te vullen in de 'dbsettings.inc.php' en kijken of de retrieve dan wel verder gaat?

Temp database + opnieuw runnen van install.php loopt ook stuk tijdens de initialisatie van de database (MYSQL error op de ROW filesize BIGINT), ik denk dat er een bug in de develop branch zit...
Switch naar Master via

code:

git checkout master
bin/upgrade-db.php

en alles werkt weer

[mesa57]

Er zijn inderdaad recent wat updates in de develop branch geweest.
Bedankt voor het melden !

[Tomba]

mesa57 schreef op dinsdag 6 augustus 2019 @ 19:27:
Er zijn inderdaad recent wat updates in de develop branch geweest.
Bedankt voor het melden !

Graag gedaan. Zit me ook af te vragen waarom ik ook alweer überhaupt de develop branch draaide Er was ooit een reden voor maar welke? Geen idee Voor nu weer helemaal happy!

[mesa57]

De nieuwste patches vind je natuurlijk op de develop branch.
Ditmaal was het echter een niet volledig geteste pull request van een andere developer.
Werkte wel goed bij hem, maar dus niet bij anderen.

[ariekanari]

pven schreef op vrijdag 12 april 2019 @ 18:18:
Hm, hij is niet helemaal in orde:

code:

$ /usr/bin/php /blaat/spotweb/retrieve.php
PHP Parse error:  syntax error, unexpected '.', expecting ',' or ';' in /blaat/spotweb/lib/SpotDebug.php on line 17
$

@Matis Ik ken de foutmelding, maar na een paar keer klikken lost ie zichzelf meestal op. Mijn usenet-server was voor de update nog bereikbaar voor het retrieve-gebeuren. Het is een klein block-account welke ik alleen voor spotweb gebruik, te veel lijntjes kan dus eigenlijk niet. Het werkt voor geen enkele spot neer, het lijkt me stug dat alle spots weg zijn.

Werkt het met de laatste update bij jou nog wel?

Kleine update: ik heb de backup terug gezet, dan werkt het weer wel zoals het hoort. Ligt dus echt ergens aan een update. Ik heb ze nu heel even naast elkaar staan in verschillende directories maar met dezelfde database. Het is overduidelijk dat het door de update komt.

Matis schreef op vrijdag 12 april 2019 @ 21:48:
@pven ikzelf heb de laatste versie van SpotWeb (nog) niet gedownload, maar jouw foutmelding leidt me naar een volgend issue: https://github.com/spotweb/spotweb/issues/408

Probeer dat eens...

Dank voor bovenstaande info.
Ik dacht laat ik Spotweb weer eens activeren op mijn Zyxel NAS520 en updaten naar een recente versie.
Hetzelfde probleem speelt ook op de Zyxel NAS520/540/542 (en mogelijk andere modellen)
Geïnstalleerde phpMyAdmin versie-informatie: 4.1.14.3, meest recente versie: 4.9.0.1.

code:

Parse error: syntax error, unexpected '.', expecting ',' or ';' in /i-data/e162cf92/www/spotweb/lib/SpotDebug.php on line 17

Vervangen en toevoegen in SpotDebug.php

code:

    static private $_logDir;
    static private $_debugLogDao = null;

    function __construct()
    {
    $_logDir = __DIR__ . '/../logs';
    }

Hierna werkt het weer met:

code:

LD_LIBRARY_PATH=/i-data/e162cf92/.PKG/PHP-MySQL-phpMyAdmin/lib
~ # /i-data/e162cf92/.PKG/PHP-MySQL-phpMyAdmin/php/bin/php /i-data/e162cf92/www/spotweb/retrieve.php

ariekanari wijzigde deze reactie 20-08-2019 17:32 (0%)
Reden: opschonen coderegel

[pven]

Spotweb op mijn Synology (DS214+) geeft al een tijdje dit soort meldingen (op de webpagina). Deze staat er heel vaak, met iedere keer een ander regelnummer. Iemand een idee hoe dit te verhelpen is? Google helpt me niet echt.

[q]Warning: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /volume1/web/spotweb/lib/SpotTemplateHelper.php on line 862
[/q]

De oplossing hier lost dit probleem overigens niet op.

Never mind, herstart over het hoofd gezien ...

pven wijzigde deze reactie 11-09-2019 16:18 (12%)

[remcoXP]

ik heb het package op mijn synology draaien met nginx en php5.6

nu heb ik de spotweb files overschreven met nieuwe en daar de update gedraaid:

code:

Notice: Undefined index: COLUMN_NAME in /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php on line 227
                Dropping index idx_commentsfull_1


SpotWeb crashed

Database schema or settings upgrade failed:
   HY000: 1553: Cannot drop index 'idx_commentsfull_1': needed in a foreign key constraint


#0 /volume1/web/spotweb/lib/dbstruct/SpotStruct_mysql.php(162): dbeng_pdo->rawExec('DROP INDEX idx_...')
#1 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(125): SpotStruct_mysql->dropIndex('idx_commentsful...', 'commentsfull')
#2 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(711): SpotStruct_abs->validateIndex('idx_commentsful...', 'UNIQUE', 'commentsfull', Array)
#3 /volume1/web/spotweb/lib/services/Upgrade/Services_Upgrade_Base.php(42): SpotStruct_abs->updateSchema()
#4 /volume1/web/spotweb/bin/upgrade-db.php(34): Services_Upgrade_Base->database()

wat kan ik hieraan doen? want de gui geeft nu aan dat ik eerst db-update.php moet draaien

[pven]

@remcoXP Heb je geprobeerd om php db-update.php vanaf de prompt te draaien?

[remcoXP]

@pven zeker. maar ik heb nu opgelost door het oude package weer te installeren
ondertussen vanuit HASS de addon gebruikt die een docker op mijn intel NUC zet. kijken of dat wat is

[Tijntje]

remcoXP schreef op woensdag 11 september 2019 @ 20:44:
ik heb het package op mijn synology draaien met nginx en php5.6

nu heb ik de spotweb files overschreven met nieuwe en daar de update gedraaid:

code:

Notice: Undefined index: COLUMN_NAME in /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php on line 227
                Dropping index idx_commentsfull_1


SpotWeb crashed

Database schema or settings upgrade failed:
   HY000: 1553: Cannot drop index 'idx_commentsfull_1': needed in a foreign key constraint


#0 /volume1/web/spotweb/lib/dbstruct/SpotStruct_mysql.php(162): dbeng_pdo->rawExec('DROP INDEX idx_...')
#1 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(125): SpotStruct_mysql->dropIndex('idx_commentsful...', 'commentsfull')
#2 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(711): SpotStruct_abs->validateIndex('idx_commentsful...', 'UNIQUE', 'commentsfull', Array)
#3 /volume1/web/spotweb/lib/services/Upgrade/Services_Upgrade_Base.php(42): SpotStruct_abs->updateSchema()
#4 /volume1/web/spotweb/bin/upgrade-db.php(34): Services_Upgrade_Base->database()

wat kan ik hieraan doen? want de gui geeft nu aan dat ik eerst db-update.php moet draaien

Dit is een issue met MySQL 8, is al een github issue voor.
https://github.com/spotweb/spotweb/issues/437

[mesa57]

Issue #437 is opgelost in de laatste commit, zowel op de master als develop branch.

[pven]

Iemand toevallig een idee hoe ik de Downloaded-lijst kan inkrimpen? Daar staan nu ongeveer alle downloads die ik ooit vanuit Spotweb heb gestart. Alleen het laden van die lijst duurt al een paar minuten. Op zich ben ik tevreden met alleen de laatste 100 entries ofzo.

Voor het beeld: ik klink linksboven op Downloaded, en krijg dan die lijst te zijn,

[SMSfreakie]

Gok dat 't wel ergens een database table is..

[pven]

SMSfreakie schreef op vrijdag 4 oktober 2019 @ 09:38:
Gok dat 't wel ergens een database table is..

De tabel heet niet letterlijk zo, dat maakt het wat lastig. Ik gok dat ergens in een veldje bij wordt gehouden wat wanneer gedownload is.

[Kroonkurk]

Linksonder staat toch een knop met erase downloadhistory ?

[pven]

Kroonkurk schreef op vrijdag 4 oktober 2019 @ 10:53:
Linksonder staat toch een knop met erase downloadhistory ?

Klopt, maar die wist alle history. Ik wil juist een X aantal entries laten staan.

Iemand een idee hoe ik de query achter die erase history kan achterhalen? Als ik de code doorzoek, dan kom ik er niet aan uit.

pven wijzigde deze reactie 04-10-2019 11:25 (20%)

[Mr_Blobby]

pven schreef op vrijdag 4 oktober 2019 @ 10:58:
[...]

Klopt, maar die wist alle history. Ik wil juist een X aantal entries laten staan.

Iemand een idee hoe ik de query achter die erase history kan achterhalen? Als ik de code doorzoek, dan kom ik er niet aan uit.

In https://github.com/spotwe...ao_Base_SpotStateList.php:

PHP:

    /*
     * Remove all downloads
     */
    function clearDownloadList($ourUserId) {
        SpotTiming::start(__CLASS__ . '::' . __FUNCTION__);
        $this->_conn->modify("UPDATE spotstatelist SET download = NULL WHERE ouruserid = :ouruserid",
            array(
                ':ouruserid' => array($ourUserId, PDO::PARAM_INT)
            ));
        SpotTiming::stop(__CLASS__ . '::' . __FUNCTION__, array($ourUserId));
    } # clearDownloadList

[pven]

Mr_Blobby schreef op vrijdag 4 oktober 2019 @ 12:40:
[...]

In https://github.com/spotwe...ao_Base_SpotStateList.php:

PHP:

    /*
     * Remove all downloads
     */
    function clearDownloadList($ourUserId) {
        SpotTiming::start(__CLASS__ . '::' . __FUNCTION__);
        $this->_conn->modify("UPDATE spotstatelist SET download = NULL WHERE ouruserid = :ouruserid",
            array(
                ':ouruserid' => array($ourUserId, PDO::PARAM_INT)
            ));
        SpotTiming::stop(__CLASS__ . '::' . __FUNCTION__, array($ourUserId));
    } # clearDownloadList

Dank je! Hier kan ik wel iets mee.

Ik heb deze aan mijn update-script toegevoegd:

PHP:

delete from spotstatelist where download < ( date_add(now(), interval -100 day) );

pven wijzigde deze reactie 04-10-2019 15:05 (9%)