SpotWeb - Webbased Spotnet - deel 2

[Verwijderd]

Hellboy! schreef op donderdag 23 mei 2013 @ 10:40:
Dat betekend dat ik per film een filter moet maken, dan word mijn scherm aardig vol. Zag in github wel een request voorbij komen over dit onderwerp.

Ik heb hiervoor een dood simpel php scriptje gemaakt die een txt file uitleest met zoektermen, die in een domme LIKE query gooit (gekoppeld met download historie), en dan SAB aanroept met de download nzb url van spotweb. Ok je krijgt wat rommel mee, mja goed genoeg voor wat nederlandse series. Scripte draait dan na een update.

[Hellboy!]

Ik merk dat spotweb niet goed omgaat met zoeken op meerdere titles als ik deze toevoeg met +, bugje?

[Mr_Robot]

nvm

[ Voor 98% gewijzigd door Mr_Robot op 25-05-2013 10:33 ]

[WoBBeL]

Zo, de blacklist is ook weer online DNS update kan nog maximaal 24 uur duren bij sommige mensen.

[sus]

Ik kan hem zo snel niet vinden, ik moet mijn usenet-server veranderen, ben van provider gewisseld. Waar vind ik die, want in settings.php zie ik hem niet staan...

[edit]
Dus... inloggen als ADMIN ipv gewone user, dat werkt...

[ Voor 18% gewijzigd door sus op 27-05-2013 22:07 ]

[Magic]

Martijn085 schreef op maandag 20 mei 2013 @ 14:28:
[...]


Dat kan zeker, deze heb ik al in de planning voor de volgende update.

Ik zie dat je een nieuwe versie hebt klaarstaan, is er ook een changelog?

[ReTechNL]

Ik heb gister spotweb geinstalleerd en heb cronjobs draaiende welke de spots updaten. Maar nu kwam ik in 1 van de log files van het updaten van de spots deze melding tegen:

code:

SpotWeb v0.58.25.29 on PHP v5.3.21 crashed

Fatal error occured while connecting to the newsserver:
  (-1) Failed to write to socket! (connection lost!) [response: ""]


#0 /volume1/web/spotweb/NNTP/Protocol/Client.php(264): Net_NNTP_Protocol_Client->throwError('Failed to write...')
#1 /volume1/web/spotweb/NNTP/Protocol/Client.php(1745): Net_NNTP_Protocol_Client->_sendCommand('XOVER 764157-76...')
#2 /volume1/web/spotweb/NNTP/Client.php(1000): Net_NNTP_Protocol_Client->cmdXOver('764157-765157')
#3 /volume1/web/spotweb/lib/SpotNntp.php(46): Net_NNTP_Client->getOverview('764157-765157')
#4 /volume1/web/spotweb/lib/retriever/SpotRetriever_Abs.php(157): SpotNntp->getOverview(764157, 765157)
#5 /volume1/web/spotweb/lib/retriever/SpotRetriever_Abs.php(230): SpotRetriever_Abs->loopTillEnd(0, '1000')
#6 /volume1/web/spotweb/retrieve.php(180): SpotRetriever_Abs->perform()
#7 {main}

Updating retrieve status in the database

Finished retrieving comments.

[MikeOO]

ReTechNL schreef op donderdag 06 juni 2013 @ 08:50:
Ik heb gister spotweb geinstalleerd en heb cronjobs draaiende welke de spots updaten. Maar nu kwam ik in 1 van de log files van het updaten van de spots deze melding tegen:

code:

SpotWeb v0.58.25.29 on PHP v5.3.21 crashed

Fatal error occured while connecting to the newsserver:
  (-1) Failed to write to socket! (connection lost!) [response: ""]


#0 /volume1/web/spotweb/NNTP/Protocol/Client.php(264): Net_NNTP_Protocol_Client->throwError('Failed to write...')
#1 /volume1/web/spotweb/NNTP/Protocol/Client.php(1745): Net_NNTP_Protocol_Client->_sendCommand('XOVER 764157-76...')
#2 /volume1/web/spotweb/NNTP/Client.php(1000): Net_NNTP_Protocol_Client->cmdXOver('764157-765157')
#3 /volume1/web/spotweb/lib/SpotNntp.php(46): Net_NNTP_Client->getOverview('764157-765157')
#4 /volume1/web/spotweb/lib/retriever/SpotRetriever_Abs.php(157): SpotNntp->getOverview(764157, 765157)
#5 /volume1/web/spotweb/lib/retriever/SpotRetriever_Abs.php(230): SpotRetriever_Abs->loopTillEnd(0, '1000')
#6 /volume1/web/spotweb/retrieve.php(180): SpotRetriever_Abs->perform()
#7 {main}

Updating retrieve status in the database

Finished retrieving comments.

Mooi dat je dit meld maar wat je heb zelf ook geprobeerd?

Even zoeken op de foutmelding en je krijgt een aantal hits.
Aangezien je verder geen info geeft wat je geprobeerd hebt is onderstaand dus waarschijnlijk van toepassing. Zo niet dan kun je het beste een ticket aanmaken bij github/spotweb.

2de link zegt al genoeg van de maker
https://github.com/spotweb/spotweb/issues/1419

NNTP gaat eigenlijk alles over (NNTP is zeg maar de naam van het protocol dat we meestal "usenet" of "newsserver" noemen) dus op het moment dat retrieve.php een verbinding maakt om nieuwe spots op te halen maakt hij feitelijk een NNTP verbinding. Spotweb doet niets achter je rug dus hij post ook niets of iets dergelijks, geen zorgen

De melding is eigenlijk vrij duidelijk, de verbinding met de usenet server is verbroken. Kan van alles zijn en normaal is het zo dat als je hem nog een keer opstart dat het probleem vanzelf verdwijnt

[GioStyle]

Na jarenlang Spotnet gebruikt te hebben ben ik nu Spotweb aan het proberen.

In MySQL database aangemaakt met daarbijhorende user. Vervolgens spotweb in wwwroot gestopt. Install.php gevolgd etc. So far so good.

Maar wanneer ik retrieve.php opvraag zegt ie Acces Denied. In welke hoek moet ik het gaan zoeken? Verbinding met MySQL is volgens mij goed en met nieuwsgroepenprovider ook.

Fixed.

[kgb545]

Kan je dan ook aangeven wat je gedaan hebt om het te fixen? Het is altijd wel fijn om dat te melden, in plaats van je bericht door te strepen. Dan hebben anderen die hetzelfde probleem hebben er ook nog wat aan namelijk (ik vermoed overigens dat je je dbsettings.inc.php niet "gevuld" had ?)

GioStyle schreef op vrijdag 07 juni 2013 @ 21:24:
Na jarenlang Spotnet gebruikt te hebben ben ik nu Spotweb aan het proberen.

In MySQL database aangemaakt met daarbijhorende user. Vervolgens spotweb in wwwroot gestopt. Install.php gevolgd etc. So far so good.

Maar wanneer ik retrieve.php opvraag zegt ie Acces Denied. In welke hoek moet ik het gaan zoeken? Verbinding met MySQL is volgens mij goed en met nieuwsgroepenprovider ook.

Fixed.

[ Voor 4% gewijzigd door kgb545 op 08-06-2013 10:29 ]

[GioStyle]

Mwah, dat wil ik op zich wel maar als ik dan dit topic doorspit en vervolgens dit soort opmerkingen lees:

PascalKroeze schreef op vrijdag 11 november 2011 @ 19:48:
[...]


Als ik retrieve.php vanuit webbrowser open krijg ik een access denied, meer info staat er niet.

Verwijderd schreef op vrijdag 11 november 2011 @ 20:10:
[...]

Je zou je natuurlijk even kunnen inlezen op de Wiki en de TS voordat je vragen gaat stellen.

Dan denk ik van.. dan zoek ik het wel zelf uit.

Bij mij lag het aan php die niet helemaal lekker deed. Ik ben van vooraf aan opnieuw begonnen en nu werkt het wel, maar nog niet helemaal. Ik krijg de recente spots niet binnen, jongste spot is nu 5 maanden.

[Martijn085]

Magic schreef op woensdag 29 mei 2013 @ 08:32:
[...]

Ik zie dat je een nieuwe versie hebt klaarstaan, is er ook een changelog?

Die wordt via de repository bekend gemaakt. Als je spotweb aanklikt op de repository zie je de changelog staan. Dit kun je alleen zien wanneer er een update beschikbaar is.

Het enige wat is aangepast is dat de Newznab provider werkt, en wat kleine aanpassingen in de rechten van de bestanden.

Wel bezig geweest met git etc. maar helaas wordt de git map rond de 20MB waardoor de package ook erg groot wordt. Het doel van de package is dat je deze makkelijk kunt installeren en zonder bootstrap. De git optie valt daardoor voor de meeste mensen al af en zal dan weinig worden gebruikt.

De updates laat ik daarom via de package updaten. Er kan natuurlijk wel een Spotweb Git versie worden gemaakt voor de liefhebbers.

Voor het toevoegen van een taak in de DSM taakplanner heb ik nog niks kunnen vinden. Via tooltjes die Synology aan boord heeft kun je niet via de commandline een DSM taakplanner taak toevoegen. Dus als iemand nog een idee heeft hoe je dit kunt doen, dan hoor ik het graag.

[Caveman]

Vraagje; Als ik een andere usenet provider invoer gaat die dan een hele nieuwe database maken of gaat ie gewoon verder waar de andere gebleven is ?

Dat eerste krijg ik weer hoofdbrekens van op mijn nasje Ik meen me te herinneren dat bij wat oudere versies zo was.

[ Voor 12% gewijzigd door Caveman op 10-06-2013 10:24 ]

[Deem]

Hij gaat volgens mij verder waar ie gebleven was.

[MikeOO]

Klopt gaat gewoon verder. Alleen niet vergeten in Spotweb de nieuwe gegevens in te vullen natuurlijk.

[Caveman]

@ Deem en MikeOO, Thx! Ga ik de nieuwe eens invullen

[Xaero]

Iemand al eigenlijk over naar de refactor branche? Werkt dat een beetje?

[DeTjuk]

Sinds gister spotweb, maar weer eens geinstalleerd.

Is er ergens te zien welke versie is geinstalleerd?

[MikeOO]

DeTjuk schreef op dinsdag 11 juni 2013 @ 10:43:
Sinds gister spotweb, maar weer eens geinstalleerd.

Is er ergens te zien welke versie is geinstalleerd?

Na installatie gewoon Git Pull uitvoeren en dan heb je de laatste versie.

[Binnetie]

Binnetie schreef op woensdag 08 mei 2013 @ 14:12:
Ik heb spotweb op een vps staan en update de spots via een cronjob, zie screenshot:

[afbeelding]

Welk commando moet je geven in de cronjob om een pull te doen en een upgrade van de database? Deze zet ik dan op 1x per week.

Iemand weet hoe ik een update doe vanuit directadmin? Dus een git pull

[WoBBeL]

op mij eigen bak kan ik gewoon dit uitvoeren:

php /var/www/spotweb/retrieve.php

Het is afhankelijk van het systeem waar het op draait. Vraag je hoster eens, die weten het vaak wel. (en je upgrade zou ik vaker doen dan 1x in de week )

[Binnetie]

Je bedoeld nu retrieve, die wordt elke 30 minuten gedaan.
Ik zal eens wat proberen...

Heb nu dit gedaan:



Code in de spotweb-upgrade.sh:

#!/bin/sh
# Alternatief upgrade script voor Spotweb.
# Plaats het script in root van Spotweb en maak een cron aan.
#
echo "Spotweb updaten..."
git pull
wait
echo "Database upgrade..."
# Command om php locatie te bepalen: "which php"
/home/binnetie/domains/mijndomeinnaam.nl/public_html/spotweb/upgrade-db.php
wait
echo "Spotweb is geupdate!"

Maar het lijk nog niet echt te werken. Dit script vond ik op internet: https://github.com/spotwe...atisch-bijwerken-op-Linux

Dit is de mail die ik van de directadmin omgeving krijg:

Failed loading /usr/local/lib/ioncube/ioncube_loader_lin_5.4.so:
/usr/local/lib/ioncube/ioncube_loader_lin_5.4.so: cannot open shared object file: No
such file or directory
Failed loading /usr/local/lib/ZendGuardLoader5.4.so:
/usr/local/lib/ZendGuardLoader5.4.so: cannot open shared object file: No such file
or directory
# Alternatief upgrade script voor Spotweb.
# Plaats het script in root van Spotweb en maak een cron aan.
#
echo "Spotweb updaten..."
git pull
wait
echo "Database upgrade..."
# Command om php locatie te bepalen: "which php"
/home/binnetie/domains/mijndomeinnaam.nl/public_html/spotweb/upgrade-db.php
wait
echo "Spotweb is geupdate!"

[ Voor 114% gewijzigd door Binnetie op 12-06-2013 17:18 ]

[MikeOO]

Binnetie schreef op woensdag 12 juni 2013 @ 15:02:
Je bedoeld nu retrieve, die wordt elke 30 minuten gedaan.
Ik zal eens wat proberen...

Heb nu dit gedaan:

[afbeelding]

Code in de spotweb-upgrade.sh:


[...]


Maar het lijk nog niet echt te werken. Dit script vond ik op internet: https://github.com/spotwe...atisch-bijwerken-op-Linux

Dit is de mail die ik van de directadmin omgeving krijg:

[...]

Ik zou het eerst handmatig proberen en als je dat werkend heb kun je evt een script gaan gebruiken. Probleem met een script is dat je vaak niet ziet waar het fout gaat omdat je dan andere foutmelding krijgt.
Alles wat een script kan zou jij zelf ook moeten kunnen desnoods voer je handmatig regel voor regel uit.

Een git pull is de manier om dit automatische te doen.
Check dus welke melding je krijgt als je vanuit de Spotweb folder een Git Pull doet.

Ik neem aan dat je wel via Putty of Telnet een verbinding kan maken naar je Spotweb van je hoster.
Dan een Git Pull proberen te doen mits je GIT hebt geïnstalleerd anders zal je deze eerst moeten installeren.

Andere optie is om zelf de laatste versie te downloaden en deze bestanden te overschrijven.

Het script doet niet veel meer dan

1. Git Pull
2. en daarna de upgrade-db.php uitvoeren die uitgevoerd moet worden na een Git Pull update.

Voor stap 2 moet je dus zorgen dat PHP ook gevonden kan worden, anders het path ervoor zetten.

[Binnetie]

Mijn contactpersoon waar ik ruimte op de VPS heb is op vakantie.
Met putty kan ik niet inloggen, dat vraag ik later wel na.

Ik kan wel een cronjob aanmaken om een upgrade-db.php te doen. Maar een git pull nog niet zolang ik geen contact heb gehad met hem.
Waar kan je de nieuwe bestanden downloaden (dat ik niet de verkeerde bestanden download)? En deze kan ik dan gewoon met FTP kopieren over de bestaande files heen? Welke files moeten niet overschreven worden? (denk aan de instellingen en gebruikersaccounts, filters gebruik ik nog niet).

[MikeOO]

Binnetie schreef op vrijdag 14 juni 2013 @ 10:14:
Mijn contactpersoon waar ik ruimte op de VPS heb is op vakantie.
Met putty kan ik niet inloggen, dat vraag ik later wel na.

Ik kan wel een cronjob aanmaken om een upgrade-db.php te doen. Maar een git pull nog niet zolang ik geen contact heb gehad met hem.
Waar kan je de nieuwe bestanden downloaden (dat ik niet de verkeerde bestanden download)? En deze kan ik dan gewoon met FTP kopieren over de bestaande files heen? Welke files moeten niet overschreven worden? (denk aan de instellingen en gebruikersaccounts, filters gebruik ik nog niet).

Ook niet met telnet?

Bestanden kun je via Github downloaden.
https://github.com/spotweb/spotweb

Klik op ZIP knopje en daar zijn ze. Daarna plaatsen en Upgrade uitvoeren.

Maar als je de recent hebt gedaan is er niet veel schokkends bij gekomen. Staat een beetje stil qua updates.

[der_roedie]

Ik probeer al een hele tijd Spotweb op mijn DS213 via cronjobs automatisch nieuwe spots binnen te laten halen.
Hiervoor gebruik ik de volgende regel in /etc/crontab

0 */2 * * * root /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null

Nou ben ik niet bekend met Cronjobs en dergelijke maar dit vertelt een timertje dat er elke 2 uur het genoemde script moet worden uitgevoerd volgens mij.

Echter er gebeurt niks, ik zie geen nieuwe Spots in Spotweb..

Vervolgens de regel uit /etc/crontab gehaald en binnen de taak planner van de DS213 het volgende toegevoegd:

cd volume1/web/spotweb && /usr/bin/php retrieve.php

Ook deze weer met een interval van 2 uur laten runnen.

Echter hier ook geen nieuwe spots in SPotweb... om gek van te worden

Als ik het bovenstaande commando (dat van de taak op de DS213) draai in Putty dan worden wel de spots binnen gehaald.

Is er ergens een log-file te vinden van de cronjobs zodat ik eens kan zien wat er daar mis gaat waarom de spots niet worden verversd?
Ik zou het toch wel handiger vinden om het automatisch te laten uitvoeren in plaats van elke keer eerst Putty starten voodat ik kijk of er nog wat leuks is op TV

[elevator]

der_roedie schreef op zaterdag 15 juni 2013 @ 11:30:
Vervolgens de regel uit /etc/crontab gehaald en binnen de taak planner van de DS213 het volgende toegevoegd:

cd volume1/web/spotweb && /usr/bin/php retrieve.php

Ik ken niks van Synologies, maar probeer eens:

cd /volume1/web/spotweb && /usr/bin/php retrieve.php

? Een relatief path gebruiken in een cronjob is nooit verstandig in ieder geval.

[der_roedie]

elevator schreef op zaterdag 15 juni 2013 @ 12:34:
[...]

Ik ken niks van Synologies, maar probeer eens:

cd /volume1/web/spotweb && /usr/bin/php retrieve.php

? Een relatief path gebruiken in een cronjob is nooit verstandig in ieder geval.

Stom inderdaad een slash vergeten maar helaas, de taak handmatig gestart en dat werkt ook niet...
om gek van te worden.

[Verwijderd]

Spotweb op windows 7 met xampp geinstalleerd.
Updaten met cmd werkt goed.
bat file gemaakt met als inhoud,

@echo off

CD D:\xampp\htdocs\spotweb

php.exe retrieve.php

exit

Als ik deze bat file uitvoer werkt het ook goed, hij gaat gewoon updaten.

Maar als ik hem laat uitvoeren door de taakplanner gaat het mis.
Alle php modules kan hij niet vinden en als laatste "Cannot open '\xamp\php\extras\browscap.ini' for reading.
Dan stopt hij helemaal.
Heb geprobeerd de rechten en bevoegdheden te veranderen van de bestanden en van de betreffende taak maar niets helpt.
Waarom werkt die bat file gewoon wel en met de taakplanner niet.?

[MikeOO]

der_roedie schreef op zaterdag 15 juni 2013 @ 21:09:
[...]


Stom inderdaad een slash vergeten maar helaas, de taak handmatig gestart en dat werkt ook niet...
om gek van te worden.

Cronjob die ik gebruik.

code:

30 * * * * root cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> /volume1/web/spotweb/errors.log

Belangrijk is dat er na het getal 30 in dit geval en root je op de TAB toets druk en geen spaties plaats anders werkt de job niet. Voor/tussen/na elk * komt dus een tab.

Zorg er ook voor nadat je iets aanpast in de cronjob je deze ook herstart anders zal hij niets doen.

code:

/usr/syno/etc/rc.d/S04crond.sh stop
/usr/syno/etc/rc.d/S04crond.sh start

Het deel >> /volume1/web/spotweb/errors.log kun je ook weglaten maar zo maakt hij een logbestand aan van de retrieve wat makkelijk is als er eens wat fout gaat.

[renzo4000]

Voor de cronjob "prutsers" zoals ik kan het veel makkelijker. Er is een package waarmee je dit simpel, en belangrijker foutloos, kan instellen naar hartelust:

http://www.cphub.net/index.php?id=40&pid=64

[grotius]

Ik probeer al enige tijd spotweb te installeren op mijn server maar de Api krijg ik niet aan de praat.

De server draait XAMPP for Solaris 1.7.7
Spotweb werkt als ik http://localhost/sportweb gebruik.
Ik draai de meest recente github (git://github.com/spotweb/spotweb.git)
Maar : http://localhost/spotweb/api?t=c geeft een 404 error (object niet gevonden).


Als ik gebruik maak van een htacces met de volgende inhoud:
RewriteEngine on
RewriteCond %{REQUEST_URI} !api/
RewriteRule api/?$ index.php?page=newznabapi [QSA]
RewriteRule details/([^/]+) index.php?page=getspot&messageid=$1 [L]
Dan is spotweb niet meer bereikbaar (access denied). Ook niet via http://localhost/sportweb

In mijn httpd.conf staat
LoadModule rewrite_module modules/mod_rewrite.so
(de ; is dus verwijderd)

en zijn alle AllowOverride op "All" gezet.

<Directory />
Options FollowSymLinks
AllowOverride All
Order deny,allow
Deny from all
Satisfy all
</Directory>

Wat doe ik verkeerd?

[der_roedie]

Nah, er is iets mis met mijn MySQL voor Spotweb op mijn Synology DS213.
Vanmiddag wilde ik kijken of de spots waren vernieuwd maar toen kreeg ik de pagina niet te zien.
Na het stoppen en starten van de webservices op de synology was de pagina weer opvraagbaar maar niets te zien.
Vervolgens handmatig via Putty het volgende gestart:

cd /volume1/web/spotweb
/usr/bin/php retrieve.php > /volume1/web/spotweb/retrieve_log.log

Maar er verschijnt niets in de logfile en ik kan ook de spotweb pagina niet meer openen....

Iemand nog suggesties en tips om de boel te repareren?

@Renzo4000: Die tool kende ik al maar ook dit hielp niks

[WoBBeL]

Gewoon '/usr/bin/php retrieve.php' uitvoeren levert ook niks op?

[grotius]

Mijn probleem is volgens mij opgelost

in de httpd.conf de volgende code toegevoegd (ipv .htaccess)

<Directory /.../spotweb/>
RewriteEngine on
RewriteCond %{REQUEST_URI} !api/
RewriteRule ^api/?$ index.php?page=newznabapi [QSA,L]
Options Indexes FollowSymLinks Multiviews
AllowOverride None
Order allow,deny
allow from all
</Directory>

[MikeOO]

der_roedie schreef op zondag 16 juni 2013 @ 18:44:
Nah, er is iets mis met mijn MySQL voor Spotweb op mijn Synology DS213.
Vanmiddag wilde ik kijken of de spots waren vernieuwd maar toen kreeg ik de pagina niet te zien.
Na het stoppen en starten van de webservices op de synology was de pagina weer opvraagbaar maar niets te zien.
Vervolgens handmatig via Putty het volgende gestart:

cd /volume1/web/spotweb
/usr/bin/php retrieve.php > /volume1/web/spotweb/retrieve_log.log

Maar er verschijnt niets in de logfile en ik kan ook de spotweb pagina niet meer openen....

Iemand nog suggesties en tips om de boel te repareren?

@Renzo4000: Die tool kende ik al maar ook dit hielp niks

Ik zou het inderdaad eerst zonder het log deel doen. Dan zie je direct wat er gebeurt. Als het eenmaal werkt kun je dat toevoegen.

Als je /usr/bin/php retrieve.php dan moet je wel iets te zien krijgen qua melding.
Heb je wel in spotweb je providergegevens ingevuld, anders kan hij niet ophalen natuurlijk.

Wat krijg je te zien als je /volume1/web/spotweb/install.php uitvoert in je internetbrowser en heb je die wel uitgevoerd bij installatie.

[der_roedie]

xost schreef op zondag 16 juni 2013 @ 19:45:
Gewoon '/usr/bin/php retrieve.php' uitvoeren levert ook niks op?

Dat is het vreemde wanneer ik :

code:

cd /volume1/web/spotweb
/usr/bin/php retrieve.php

uitvoer dan gaat het wel goed.....

[MikeOO]

der_roedie schreef op zaterdag 22 juni 2013 @ 13:28:
[...]


Dat is het vreemde wanneer ik :

code:

cd /volume1/web/spotweb
/usr/bin/php retrieve.php

uitvoer dan gaat het wel goed.....

Ik zou Spotweb en alles wat erbij hoort eens verwijderen en het dan via de Package proberen. Mogelijk dat je het dan wel werkend krijgt wat je doet ergens iets niet helemaal goed.

http://synology.mdevries.org/

Deze link toevoegen in DSM en dan zie je de package er tussen staan.
http://synology.mdevries.org/spkrepo/packages

[remcoXP]

ik zie nu dat er twee branches van spotweb zijn.

een master en een refactor. iemand ervaring met de refactor aangezien die wel meer wordt bijgewerkt.

kan ik alleen door de bestanden te overschrijven op mijn synology de andere spotweb gebruiken? of moet de database ook veranderen?

[der_roedie]

MikeOO schreef op maandag 24 juni 2013 @ 07:47:
[...]


Ik zou Spotweb en alles wat erbij hoort eens verwijderen en het dan via de Package proberen. Mogelijk dat je het dan wel werkend krijgt wat je doet ergens iets niet helemaal goed.

http://synology.mdevries.org/

Deze link toevoegen in DSM en dan zie je de package er tussen staan.
http://synology.mdevries.org/spkrepo/packages

Hoe kan ik alles van Spotweb verwijderen? MySQL database wegknikkeren en de web-folder verwijderen?
Of mis ik dan nog wat?
Ik heb al eens eerder Spotweb verwijderd en geinstalleerd via de package maar toen werkte het ook niet, wellicht toen nog iets niet verwijderd.

[NiGeLaToR]

Helemaal blij heb ik de mdevries package voor Synology geinstalleerd en het werkt tot zover prima.
Enige probleempje is het ophalen van de spots middels retrieve.php. De volgende melding komt naar voren:

PHP Fatal error: Call to undefined function mysql_connect() in /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php on line 27

Het irritante is dat dit een makkelijke melding is; ik heb gechecked of in PHP de juiste onderdelen voor MySQL aan staan, gechecked of de config goed is, de MySQL server draait, de PHP config goed staat en zover staat alles goed - maar werkt het niet. Ook in de voorgaande topics deze melding paar keer gevonden en ook de oplossingen die daar stonden geprobeerd - wat zie ik over het hoofd?

[MikeOO]

der_roedie schreef op maandag 24 juni 2013 @ 19:28:
[...]


Hoe kan ik alles van Spotweb verwijderen? MySQL database wegknikkeren en de web-folder verwijderen?
Of mis ik dan nog wat?
Ik heb al eens eerder Spotweb verwijderd en geinstalleerd via de package maar toen werkte het ook niet, wellicht toen nog iets niet verwijderd.

Inderdaad is dat wat je moet verwijderen.
Als je de package heb geïnstalleerd dan ga je via de internetbrowser naar

<IP-adres waar spotweb op staat>/spotweb/install.php

en controleer je of alles ok is. Als er iets ontbreekt dan krijg je dat daar te zien en moet je dat eerst oplossen. Bijna alles moet op OK staan. Zijn een paar uitzonderingen maar als je dan even via Google zoekt op de melding dan kom je er snel achter of deze melding wel of niet OK moet zijn.

[der_roedie]

Hmmmzzz....

ik heb toch nog eens die crontool van een paar replies terug geinstalleerd en vervolgens eens naar de log daarvan gekeken.
Ik laat via de cronjob de volgende regel uitvoeren:

code:

cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> retrieve.log

Als ik dan in de logfile kijk die aangemaakt wordt, dan zie ik staan 'Access Denied'

Wanneer ik dezelfde regel uitvoer in SSH dan gaat het wel goed en worden de spots gedownload.
Iemand nog een idee waarom ik via de Cronjob een access denied krijg?

[boswandeling]

Allowa,

Na een weekend knutselen (vorig weekend) heb ik op een Virtuele machine (esxi) een Ubuntu installatie gedaan en Spotweb geinstalleerd.

Het werkt perfect, moest helaas wel de apache poort wijzigen naar poort 83 omdat ik op poort 80 een andere vhost al ispconfig draai.

Cron gaat elk uur update doen maar het probleem dat ik heb is dat als ik inlog op spotweb en ik op "ophalen" klik er staat dat er nieuwe posts zijn, daarna verschijnt de update tijd van de laatste "ophaal" actie en die staat dan nog op 34 minuten.

Geeft wel aan nieuwe berichten laatste update staat op 34 minuten en overigens zijn er geen nieuwe spots bij gekomen.

Iemand een idee wat ik verkeerd doe of naar moet kijken. Ben al een tijdje aan het stoeien ermee, maar kom er tot dusver niet uit.

EDIT

Ik ben er nu achter gekomen dat hij ook niet update via CRON.

[ Voor 4% gewijzigd door boswandeling op 27-06-2013 18:49 ]

[NiGeLaToR]

Bij mij geeft retrieve.php nog altijd deze melding:

PHP Fatal error: Call to undefined function mysql_connect() in /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php on line 27

Knap irritant

[MikeOO]

der_roedie schreef op donderdag 27 juni 2013 @ 16:24:
Hmmmzzz....

ik heb toch nog eens die crontool van een paar replies terug geinstalleerd en vervolgens eens naar de log daarvan gekeken.
Ik laat via de cronjob de volgende regel uitvoeren:

code:

cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> retrieve.log

Als ik dan in de logfile kijk die aangemaakt wordt, dan zie ik staan 'Access Denied'

Wanneer ik dezelfde regel uitvoer in SSH dan gaat het wel goed en worden de spots gedownload.
Iemand nog een idee waarom ik via de Cronjob een access denied krijg?

En wat staat er voor deze regel. Je moet namelijk ook de root gebruiker erbij vermelden. Als dat er niet bij staat dan klopt de melding ook direct. Staat dat er wel bij dan moet je nakijken of retrieve.php wel de juisten rechten heeft zodat ROOT dit mag uitvoeren.

code:

30 * * * * root cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> retrieve.log

[ Voor 9% gewijzigd door MikeOO op 29-06-2013 08:15 ]

[MikeOO]

NiGeLaToR schreef op vrijdag 28 juni 2013 @ 14:23:
Bij mij geeft retrieve.php nog altijd deze melding:

PHP Fatal error: Call to undefined function mysql_connect() in /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php on line 27

Knap irritant

En wat heb je al geprobeerd. Alleen een foutmelding aangeven en meer niet daar kunnen wij ook niets mee.

1. Staat SQL wel aangevinkt in DSM
2. Wat geeft install.php van spotweb aan als je dat uitvoert.
3. Als dat allemaal ok is dan maakt je via een topic aan bij Spotweb.

Je kunt daar ook zoeken. Dit topic is dezelfde fout alleen geen reactie meer van Binnetie maar is ook actief op Tweakers dus misschien even een DM naar hem sturen.

[NiGeLaToR]

MikeOO schreef op zaterdag 29 juni 2013 @ 08:23:
[...]


En wat heb je al geprobeerd. Alleen een foutmelding aangeven en meer niet daar kunnen wij ook niets mee.

1. Staat SQL wel aangevinkt in DSM
2. Wat geeft install.php van spotweb aan als je dat uitvoert.
3. Als dat allemaal ok is dan maakt je via een topic aan bij Spotweb.

Je kunt daar ook zoeken. Dit topic is dezelfde fout alleen geen reactie meer van Binnetie maar is ook actief op Tweakers dus misschien even een DM naar hem sturen.

Dank voor je reactie; paar posts erboven mijn relaas gedaan:

- mysql draait
- mysql extenties staan aan in php / op de webserver
- spotweb install.php geeft geen errors
- spotweb draait prima, zonder spots

Kan de foutmelding dus niet plaatsen. Voer het commando uit als root, maar toch die melding. Ik ga nog even verder speuren en anders een nieuw topic voor aanmaken. We komen er wel

[Eboman]

Ik heb een synology DS213+ , maar als ik een api call doe naar spotweb dan duurt dit te lang voor bv CP en resulteert in een timeout in CP, ook als ik de URL aanroep via een browser krijg ik dus wel output, maar het duurt vrij lang (ongeveer 70 seconden) bij een api call zoeken in de films met een imdbid. Ik ben momenteel de full spots aan het ophalen,maar zijn er nog meer mogelijkheden dit te versnellen ? Ik heb de volgende instructie gevolgd http://synology.brickman....-%20install%20Spotweb.txt en werk met een .htaccess file. Dit is een verse install dus verder niets aangepast of getweaked..

edit:hmm, een snel testje leert dat een nieuwe post met full postings 10 seconden duurt, is dit logisch ? Is full postings een vereiste als je newsnab wil draaien ?

[ Voor 11% gewijzigd door Eboman op 29-06-2013 15:56 ]

[der_roedie]

MikeOO schreef op zaterdag 29 juni 2013 @ 08:13:
[...]


En wat staat er voor deze regel. Je moet namelijk ook de root gebruiker erbij vermelden. Als dat er niet bij staat dan klopt de melding ook direct. Staat dat er wel bij dan moet je nakijken of retrieve.php wel de juisten rechten heeft zodat ROOT dit mag uitvoeren.

code:

30 * * * * root cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> retrieve.log

Ja, dat staat er allemaal voor natuurlijk. Maar ik blijf die access denied error houden. Zou het ermee te maken kunnen hebben dat het wachtwoord voor root in php anders is dan voor ssh?

Zo maar eens even proberen.

[MikeOO]

der_roedie schreef op zaterdag 29 juni 2013 @ 21:01:
[...]


Ja, dat staat er allemaal voor natuurlijk. Maar ik blijf die access denied error houden. Zou het ermee te maken kunnen hebben dat het wachtwoord voor root in php anders is dan voor ssh?

Zo maar eens even proberen.

Root gebruiker is hetzelfde dus dat lijkt mij niet. Ik zou toch eens naar je rechten gaan kijken in de Spotweb map.

Met WINSCP kun je dit eenvoudig zien.

Inloggen en dan rechtermuisknop op bestand of map en kies voor eigenschappen en je ziet welke rechten het heeft.
Check ook gelijk of de /web/spotweb folder wel ROOT als eigenaar heeft. Anders krijg je ook dit soort problemen.

[MikeOO]

NiGeLaToR schreef op zaterdag 29 juni 2013 @ 14:36:
[...]


Dank voor je reactie; paar posts erboven mijn relaas gedaan:

- mysql draait
- mysql extenties staan aan in php / op de webserver
- spotweb install.php geeft geen errors
- spotweb draait prima, zonder spots

Kan de foutmelding dus niet plaatsen. Voer het commando uit als root, maar toch die melding. Ik ga nog even verder speuren en anders een nieuw topic voor aanmaken. We komen er wel

Ik zou even een topic aanmaken bij Spotweb. Dan is het meestal snel opgelost.

[der_roedie]

MikeOO schreef op zondag 30 juni 2013 @ 07:49:
[...]


Root gebruiker is hetzelfde dus dat lijkt mij niet. Ik zou toch eens naar je rechten gaan kijken in de Spotweb map.

Met WINSCP kun je dit eenvoudig zien.

Inloggen en dan rechtermuisknop op bestand of map en kies voor eigenschappen en je ziet welke rechten het heeft.
Check ook gelijk of de /web/spotweb folder wel ROOT als eigenaar heeft. Anders krijg je ook dit soort problemen.

Alles 777 dus OK.
Ik snap er niks meer van.
Spotweb ook al geinstalleerd via de package op mijn Synology maar updaten blijft een drama.
Ik ga, net zoals hierboven, ook maar een topic aanmaken op het GitHub/Spotweb forum

[MikeOO]

der_roedie schreef op zondag 30 juni 2013 @ 08:24:
[...]


Alles 777 dus OK.
Ik snap er niks meer van.
Spotweb ook al geinstalleerd via de package op mijn Synology maar updaten blijft een drama.
Ik ga, net zoals hierboven, ook maar een topic aanmaken op het GitHub/Spotweb forum

Wat mij nu ineens opvalt is
cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> retrieve.log

Maar probeer het eens met

cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> /volume1/web/spotweb/retrieve.log


Mogelijk dat de Access Denied komt omdat hij de retrieve.log wil wegschrijven naar een plek waar dit niet mag.

[ReTechNL]

Hier het zelfde probleem
Starten via SSH gaat prima maar op het moment dat is een scheduled job aanmaak in de crontab dan draait hij wel maar ik krijg de melding Access Denied.

NAS: Synology DS413j

/volume1/homes/admin/Logs/spotweb/retr_2013_07_02_15_00.log

code:

======================
2013-07-02 15:00: Starting retrieval of new spots for Spotweb

Access denied
2013-07-02 15:00: Retrieval of new spots ended
======================

code:

/var/log/cron.log
Jul 02 06:00:01 crond: USER root pid 15393 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 07:00:01 crond: USER root pid 16339 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 08:00:01 crond: USER root pid 17279 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 09:00:01 crond: USER root pid 18223 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 10:00:01 crond: USER root pid 19161 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 11:00:01 crond: USER root pid 20109 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 12:00:01 crond: USER root pid 21052 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 13:00:01 crond: USER root pid 21994 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 14:00:01 crond: USER root pid 22934 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null
Jul 02 15:00:01 crond: USER root pid 23883 cmd /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null

crontab

code:

53  11  *   *   3,6 root    /usr/syno/bin/synopkg chkupgradepkg
13  6   *   *   3,6 root    /usr/bin/php -n -d safe_mode_exec_dir='' /usr/syno/bin/autoupdate.php
15  *   6   *   *   root    /bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh > /dev/null  #spotweb updaten
0   *   *   *   *   root    /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /dev/null #spotweb spots ophalen
*   1   1   *   *   root    cd /volume1/web/spotweb && /usr/bin/php upgrade-db.php  #spotweb database updaten

[der_roedie]

MikeOO schreef op maandag 01 juli 2013 @ 08:34:
[...]


Wat mij nu ineens opvalt is
cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> retrieve.log

Maar probeer het eens met

cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> /volume1/web/spotweb/retrieve.log


Mogelijk dat de Access Denied komt omdat hij de retrieve.log wil wegschrijven naar een plek waar dit niet mag.

Hij maakt de logfile netjes aan in de folder waar je als eerste naar toe gaat met het change dir commando.
Als ik dan in die logfile kijk staat daar 'Access Denied' in.

blijkbaar niet ik niet de enige met dit probleem. Vind het erg irritant dat ik nu steeds via SSH moet updaten, hopelijk komen we snel tot een oplossing.
Op GitHub krijg ik in ieder geval geen response helaas.

[MikeOO]

der_roedie schreef op dinsdag 02 juli 2013 @ 21:13:
[...]


Hij maakt de logfile netjes aan in de folder waar je als eerste naar toe gaat met het change dir commando.
Als ik dan in die logfile kijk staat daar 'Access Denied' in.

blijkbaar niet ik niet de enige met dit probleem. Vind het erg irritant dat ik nu steeds via SSH moet updaten, hopelijk komen we snel tot een oplossing.
Op GitHub krijg ik in ieder geval geen response helaas.

Persoonlijk zou ik wel het path erbij vermelden zodat de logfile altijd daar wordt aangemaakt maar dat is een eigen keuze.

Probeer eens in Putty het volgende te starten vanuit de Spotweb folder. Deze hersteld ook een aantal rechten.

code:

/usr/bin/php upgrade-db.php

Deze regel dien je altijd uit te voeren na een Git Pull. Mogelijk dat jullie dat niet gedaan hebben.
Een keer extra starten kan geen kwaad en en na uitvoeren en als hij klaar is nog eens via de cronjob de retrieve testen.

[der_roedie]

MikeOO schreef op woensdag 03 juli 2013 @ 10:05:
[...]


Persoonlijk zou ik wel het path erbij vermelden zodat de logfile altijd daar wordt aangemaakt maar dat is een eigen keuze.

Probeer eens in Putty het volgende te starten vanuit de Spotweb folder. Deze hersteld ook een aantal rechten.

code:

/usr/bin/php upgrade-db.php

Deze regel dien je altijd uit te voeren na een Git Pull. Mogelijk dat jullie dat niet gedaan hebben.
Een keer extra starten kan geen kwaad en en na uitvoeren en als hij klaar is nog eens via de cronjob de retrieve testen.

Ga ik vanavond even doen, ik had gisteren ook nog wat scripts gedraaid die ik ergens had gevonden voor een handmatige installatie van Spotweb en daarna de cronjobs aangemaakt (met logging) maar geen logfile te vinden.

Hoe zou ik kunnen testen of mijn cronjobs wel getriggered worden?

[FitzJac]

Zoiets? komt er elke minuut test en de datum in een file crontest te staan in je home directory:

code:

*/1 * * * * echo "test $(date)" >> ~/crontest

[MikeOO]

der_roedie schreef op woensdag 03 juli 2013 @ 14:31:
[...]


Ga ik vanavond even doen, ik had gisteren ook nog wat scripts gedraaid die ik ergens had gevonden voor een handmatige installatie van Spotweb en daarna de cronjobs aangemaakt (met logging) maar geen logfile te vinden.

Hoe zou ik kunnen testen of mijn cronjobs wel getriggered worden?

Heb je toevallig geen spaties in je cronjob regel staan ipv TABS. Dan loopt hij ook niet.
En logging nu wel aangemaakt met het pad ervoor zodat je zeker weet dat hij op de juiste plek komt.

En zorg altijd dat je een herstart doet van de cronjob.

[der_roedie]

Ik heb geen spaties in de cronjob regel staan, heb ik ook al tig keer gecontroleerd.
Ik ga vanavond even dat test scriptje testen om te zien of mijn cronjobs wel getriggered worden.

[der_roedie]

FitzJac schreef op woensdag 03 juli 2013 @ 15:41:
Zoiets? komt er elke minuut test en de datum in een file crontest te staan in je home directory:

code:

*/1 * * * * echo "test $(date)" >> ~/crontest

Nou dat werkt gewoon... zucht. Never ending story dat retrieven.

[MikeOO]

der_roedie schreef op donderdag 04 juli 2013 @ 22:57:
[...]


Nou dat werkt gewoon... zucht. Never ending story dat retrieven.

Post anders eens je hele cronjob inhoud en tevens de locatie en bestandnaam van de cronjob die je gebruikt.

[chatman1810]

Ik heb een probleem waar ik graag jullie hulp voor zou willen vragen. Sinds kort een Synology icm spotweb, sickbeard, nzbget. Alles werkt uitstekend binnen spotweb, binnen enkele seconden opent een post en krijg ik ook zoek resultaten terug. Als ik echter een API call doe vanuit Sickbeard of de webbrowser duurt dit zeer lang (minuut of langer), de API test functie xml krijg ik wel direct terug. Ben gaan snuffelen in MySQL en het blijkt dat als er een APU call van Sickbeard komt voor een TV serie dat MySQL een slow query doet die uiteindelijk wel resultaat opleverd maar voor Sickbeard duurt dit veel te lang. Middels explain en profiling kwam ik erachter dat de API call een MySQL query doet welke de volledige spots/spotsfull tabellen scant ipv de indexen (althans dat vermoed ik). Ik heb verschillende posts gezien op fora van mensen die dit fenomeen (trage api) ook hebben alleen geen oplossingen. Alles is up-to-date qua software versies. Suggesties ?

[elevator]

Switch eens naar de refactor branch, volgens dit issue op Github: https://github.com/spotweb/spotweb/issues/1818 lost het dat op.

[chatman1810]

chatman1810 in "SpotWeb - Webbased Spotnet - deel 2"

elevator schreef op vrijdag 05 juli 2013 @ 09:58:
Switch eens naar de refactor branch, volgens dit issue op Github: https://github.com/spotweb/spotweb/issues/1818 lost het dat op.

Dank je wel, toevallig (want het laat me niet los) had ik dit incident net gevonden en ga vanavond overschakelen naar de refactor branch. Dank je wel voor je input !

[der_roedie]

Voor de liefhebbers:

locatie van het cron bestand: /etc/crontab

Inhoud hiervan:

code:

20  1   *   *   1,4 root    /usr/syno/bin/synopkg chkupgradepkg
15  */6 *   *   *   root    /bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh > /volume1/web/spotweb/update.log
0   */2 *   *   *   root    /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /volume1/web/spotweb/retrieve.log
13  *   *   *   *   root    /var/packages/Webalizer/target/bin/webalizer -c /var/packages/Webalizer/target/webalizer.conf
5   0   *   *   *   root    /tmp/synoschedtask --run id=2
#*/1    *   *   *   *   root    echo "Test $(date)" >> /volume1/web/spotweb/crontest.log

Wanneer ik trouwens een van de spotweb scripts draai vanuit SSH die ook in de cronjobs staan, dan gebeurt er ook niks. Geen output even een kleine pause en vervolgens weer de prompt. Als ik naar de folder ga dan zie ik die scripts wel staan.

[ Voor 16% gewijzigd door der_roedie op 05-07-2013 20:48 ]

[elevator]

Ik gok eigenlijk dat je probleem komt omdat Spotweb niet herkent dat je een SSH sessie hebt, de access denied melding komt namelijk overeen met dit: https://github.com/spotwe...b/master/retrieve.php#L79

Ik zie dat soort code niet in de refactor branch, dus ik zou eens proberen daar naar over te schakelen (google even naar 'git change branch' oid) en kijken wat die doet.

[MikeOO]

der_roedie schreef op vrijdag 05 juli 2013 @ 17:27:
Voor de liefhebbers:

locatie van het cron bestand: /etc/crontab

Inhoud hiervan:

code:

20  1   *   *   1,4 root    /usr/syno/bin/synopkg chkupgradepkg
15  */6 *   *   *   root    /bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh > /volume1/web/spotweb/update.log
0   */2 *   *   *   root    /bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /volume1/web/spotweb/retrieve.log
13  *   *   *   *   root    /var/packages/Webalizer/target/bin/webalizer -c /var/packages/Webalizer/target/webalizer.conf
5   0   *   *   *   root    /tmp/synoschedtask --run id=2
#*/1    *   *   *   *   root    echo "Test $(date)" >> /volume1/web/spotweb/crontest.log

Wanneer ik trouwens een van de spotweb scripts draai vanuit SSH die ook in de cronjobs staan, dan gebeurt er ook niks. Geen output even een kleine pause en vervolgens weer de prompt. Als ik naar de folder ga dan zie ik die scripts wel staan.

Pas deze 2 regels eens aan

code:

/bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh > /volume1/web/spotweb/update.log
/bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /volume1/web/spotweb/retrieve.log

Naar

code:

/bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh >> /volume1/web/spotweb/update.log
/bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh >> /volume1/web/spotweb/retrieve.log

Volgens mij mist er namelijk een >. Maar mogelijk dat met een SH bestand 1 > voldoende is. Bij een PHP regel moeten het wel 2x >> zijn namelijk.

Daarna wel je Cronjob weer herstarten.

[ Voor 4% gewijzigd door MikeOO op 06-07-2013 08:38 ]

[der_roedie]

De enkele of dubbele > bepaald wat er met de koffie gebeurd. Met een enkele > wordt de logfile overschreven en met een dubbele > wordt er aan de logfile toegevoegd.

Bij een vriend van me staat het ook zo en wordt de boel wel geüpdatet.

[MikeOO]

der_roedie schreef op zaterdag 06 juli 2013 @ 10:01:
De enkele of dubbele > bepaald wat er met de koffie gebeurd. Met een enkele > wordt de logfile overschreven en met een dubbele > wordt er aan de logfile toegevoegd.

Bij een vriend van me staat het ook zo en wordt de boel wel geüpdatet.

Je geeft aan dat er een kleine pauze is en dan weer terug op de prompt.

Als je het log deel eens verwijderd en dan uitvoer krijg je dan te zien wat hij voor melding heeft. De pauze betekend dat hij wel iets doet alleen vreemd dat er niets in de logfile komt. Als hij zonder de logfile wel een melding geeft dan klopt dat niet aangezien dat ook in de logfile moet komen te staan.

Wat mij ook opvalt is dat hij 2 scripts gebruikt om bij te werken. Heb je de rechten ook eens gecontroleerd in de map : /volume1/@appstore/scripts en dat beide bestanden ook uitvoer rechten hebben voor ROOT.

Probeer anders toch eens deze manier ipv de scripts om te zien of het dan wel werkt.

code:

30 * * * * root cd /volume1/web/spotweb && /usr/bin/php retrieve.php >> /volume1/web/spotweb/errors.log

[der_roedie]

Nou ja.... gisteren hing MySQL, spotweb en wordpress waren niet te bereiken. Synology herstart en sindsdien krijg ik via Prowl elke 2 uur netjes een melding dat nieuwe spots zijn binnengehaald

Ik had dit de laatste weken al vaker gedaan maar toen heeft het het probleem niet opgelost. Nu blijkbaar wel.. Ben benieuwd voor hoelang maar goed voor nu werkt het allemaal OK.

Iedereen bedankt voor het meedenken en het geven van advies. Helaas is er weinig te melden over de exacte oorzaak van het probleem zodat andere gebruikers hier ook wat aan hebben, behalve de herstart van de Synology dan.

[chatman1810]

chatman1810 schreef op vrijdag 05 juli 2013 @ 10:01:
chatman1810 in "SpotWeb - Webbased Spotnet - deel 2"

[...]


Dank je wel, toevallig (want het laat me niet los) had ik dit incident net gevonden en ga vanavond overschakelen naar de refactor branch. Dank je wel voor je input !

Helaas, ik heb dit weekend de spotweb helemaal opnieuw opgebouwd op basis van de refactor branch en ook dan is de API call vanuit sickbeard of browser zeer traag. Ben nu door de opties heen, wellicht maar een spotweb server opbouwen op een ander systeem dan de synology.

[Kozzmozz]

MikeOO schreef op zaterdag 06 juli 2013 @ 08:36:
[...]


Pas deze 2 regels eens aan

code:

/bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh > /volume1/web/spotweb/update.log
/bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh > /volume1/web/spotweb/retrieve.log

Naar

code:

/bin/sh /volume1/@appstore/scripts/spotweb_cron_upd.sh >> /volume1/web/spotweb/update.log
/bin/sh /volume1/@appstore/scripts/spotweb_cron_retr.sh >> /volume1/web/spotweb/retrieve.log

Volgens mij mist er namelijk een >. Maar mogelijk dat met een SH bestand 1 > voldoende is. Bij een PHP regel moeten het wel 2x >> zijn namelijk.

Daarna wel je Cronjob weer herstarten.

Ik had ook lange tijd geen update/retrieve bij mijn SPOTWEB-installatie op de Synology 1513+.
Maar dankzij de tip van 2x >> te gebruiken en de Cronjob terug op te starten is de oplossing.
Waarvoor dank.

[ReTechNL]

In middels alles verwijderd en helemaal opnieuw begonnen voor de zoveelste keer. Alleen dit maal met de refactor branche. Alles lijkt nu als een zonnetje te lopen. maar de tijd zal het moeten leren aangezien die nu de gehele database nog moet gaan vullen.

[raven22]

Ik heb eens zitten puzzelen om een filter toe te voegen. Maar dat wil nog niet lukken. Ik wil graag alle books met als genre 'youth' zichtbaar maken, hoe doe ik dat?

[MikeOO]

raven22 schreef op vrijdag 12 juli 2013 @ 09:41:
Ik heb eens zitten puzzelen om een filter toe te voegen. Maar dat wil nog niet lukken. Ik wil graag alle books met als genre 'youth' zichtbaar maken, hoe doe ik dat?

Misschien heb je hier iets aan.
http://www.brainbytez.nl/spotweb-filter-creator/

[raven22]

MikeOO schreef op zaterdag 13 juli 2013 @ 07:52:
[...]


Misschien heb je hier iets aan.
http://www.brainbytez.nl/spotweb-filter-creator/

Dank, die kende ik nog niet. Ga er eens even mee aan de slag.

[elevator]

Wat lukt er niet dan? Je kiest in de boom gewoon Image -> Books -> Genre -> Youth. Je zoekt, en vervolgens klik je op "save filter" ?

[raven22]

elevator schreef op zaterdag 13 juli 2013 @ 15:04:
Wat lukt er niet dan? Je kiest in de boom gewoon Image -> Books -> Genre -> Youth. Je zoekt, en vervolgens klik je op "save filter" ?

Mijn boom gaat niet verder dan Image - Books en dan of engels of nl of anders

[elevator]

Klik eens op het zoekveldje? Je krijgt dan in de linkerbalk een andere boom die je volledig uit kan klappen. Als je die niet krijgt, krijg je wel een knop die iets heet als 'Use categories', klik daar op en je kan je eigen filter samenstellen.

[raven22]

elevator schreef op maandag 15 juli 2013 @ 06:57:
Klik eens op het zoekveldje? Je krijgt dan in de linkerbalk een andere boom die je volledig uit kan klappen. Als je die niet krijgt, krijg je wel een knop die iets heet als 'Use categories', klik daar op en je kan je eigen filter samenstellen.

kijk, weer wat geleerd, dank je

[Staatslot]

Ik heb spotweb schoon geïnstalleerd op een ubtuntu vm, vannacht lekker de retrieve laten lopen.
Vanmorgen zie ik de error:

"error writing file /tmp/MYMsuDO3 (errorcode: 28)"

De /tmp is gewoon schrijfbaar, niet vol o.i.d.

Hij heeft 13.1 GiB in de database weten te zetten, tot januari 2012.

Al gezocht maar kom de error niet tegen in het forum.
Iemand een idee wat er fout gaat?

edit: in deel 1 wel, huiser in "SpotWeb - Webbased Spotnet"
Ga ik vanavond maar proberen..

[ Voor 13% gewijzigd door Staatslot op 19-07-2013 07:09 ]

[pven]

Als je de retrieve nu weer laat lopen, wat doet hij dan? (Volgens mij gaat ie verder waar ie gebleven was.)

[ Voor 31% gewijzigd door pven op 19-07-2013 07:10 ]

[Staatslot]

pven schreef op vrijdag 19 juli 2013 @ 07:09:
Als je de retrieve nu weer laat lopen, wat doet hij dan?

exact hetzelfde, direct boem foutmelding.
Ook de machine al eens herstart, hielp ook niet

[MikeOO]

Staatslot schreef op vrijdag 19 juli 2013 @ 07:07:
Ik heb spotweb schoon geïnstalleerd op een ubtuntu vm, vannacht lekker de retrieve laten lopen.
Vanmorgen zie ik de error:

"error writing file /tmp/MYMsuDO3 (errorcode: 28)"

De /tmp is gewoon schrijfbaar, niet vol o.i.d.

Hij heeft 13.1 GiB in de database weten te zetten, tot januari 2012.

Al gezocht maar kom de error niet tegen in het forum.
Iemand een idee wat er fout gaat?

edit: in deel 1 wel, huiser in "SpotWeb - Webbased Spotnet"
Ga ik vanavond maar proberen..

Lijkt toch echt op een probleem met ruimte.

http://stackoverflow.com/...ing-file-error-errcode-28
http://stackoverflow.com/...ple-joins/3716778#3716778

en anders nog meer
https://www.google.nl/sea...713905c7&biw=1920&bih=865

[Staatslot]

Ik zie het inderdaad, heb meerdere servers geinstalleerd en bleek een ander te zijn waar temp files stonden die vol was.. thanks!

[LiquidSmoke]

Zijn er hier al mensen die op de refactor branch draaien?

Ben benieuwd of de zaak stabiel genoeg is om al over te gaan,,,

[Kalua]

Heb problemen om de newznab functie icm sickbeard/couchpotato aan de praat te krijgen(op een synology NAS).. Sickbeard geeft bijvoorbeeld elke keer een timeout op de link. Als ik die dan handmatig in de browser plak, krijg ik gewoon valide xml terug. Iemand een idee?

Ik krijg bij sickbeard een error loading url

gewoon http:// in sickbeard ervoor zetten lost het op

[ Voor 9% gewijzigd door Kalua op 01-08-2013 15:44 ]

[WoBBeL]

Ik word gek ik ben niet zo'n linux held, en laatst was de upgrade naar Ubuntu server 12.10 niet helemaal goed gegaan. Apache2 en PHP opnieuw geinstalleerd en alles lijkt weer te werken maar alle Sickbeard en Couchpotato kunnen niet meer zoeken via Spotweb (via Newznab).

Spotweb is te benaderen via http://10.0.0.2/spotweb en dat werkt prima (spotweb staat in /var/www/spotweb)

De API doet het ook, ik kan namelijk naar http://10.0.0.2/api en naar http://10.0.0.2/spotweb/api en dan krijg ik netjes een XML foutcode met "Missing parameter".

Maar als Sickbeard iets probeert te zoeken krijg ik een foutmelding:

code:

"Error loading Spotweb URL: http://10.0.0.2/spotweb/api?q=2013.07&apikey=19a3b3ac020dd03c17a87a52d4cf7a71&limit=100&t=tvsearch&season=2013&rid=6753&maxage=1100&cat=5030%2C5040"

Als ik deze URL open krijg ik een HTTP Error 500, maar hierover staat niks in Apache2 error.logs, en in access.log zie ik gewoon dat ik het bestand aanroep.

Als ik spotweb probeer te updaten krijg ik netjes de melding dat die up2date is

code:

roy@server:/var/www/spotweb$ sudo git pull
Already up-to-date.

[update 20:24]

Deze URL doet het ook niet:

code:

http://10.0.0.2/spotweb/api?q=2013.07&apikey=19a3b3ac020dd03c17a87a52d4cf7a71&limit=100&t=tvsearch&season=2013&rid=6753&maxage=1100&cat=5030%2C5040

Maar als ik de "rid" value weghaal dan doet hij het ineens wel

[update 20:58]
Raar, een MySQL 'OPTIMIZE' commando op alle tabellen schijnt te helpen. Raar

[ Voor 21% gewijzigd door WoBBeL op 02-08-2013 20:58 ]

[MikeOO]

@xost

Ik zou je API key verwijderen en tevens direct een andere aanmaken voordat iemand er mogelijk misbruik van maakt.

[WoBBeL]

MikeOO schreef op zaterdag 03 augustus 2013 @ 08:20:
@xost

Ik zou je API key verwijderen en tevens direct een andere aanmaken voordat iemand er mogelijk misbruik van maakt.

M'n server is niet van buitenaf te benaderen, dus m'n API key maakt niet uit en mocht hij van buitenaf te benaderen zijn dan ben je automatisch ingelogd met de user waar deze API key bijhoort.

[ Voor 15% gewijzigd door WoBBeL op 03-08-2013 09:41 ]

[NiGeLaToR]

NiGeLaToR schreef op maandag 24 juni 2013 @ 22:02:
Helemaal blij heb ik de mdevries package voor Synology geinstalleerd en het werkt tot zover prima.
Enige probleempje is het ophalen van de spots middels retrieve.php. De volgende melding komt naar voren:

PHP Fatal error: Call to undefined function mysql_connect() in /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php on line 27

Het irritante is dat dit een makkelijke melding is; ik heb gechecked of in PHP de juiste onderdelen voor MySQL aan staan, gechecked of de config goed is, de MySQL server draait, de PHP config goed staat en zover staat alles goed - maar werkt het niet. Ook in de voorgaande topics deze melding paar keer gevonden en ook de oplossingen die daar stonden geprobeerd - wat zie ik over het hoofd?

Iemand nog een suggestie op deze? Tot op heden nog niet op weten te lossen helaas.

[WoBBeL]

NiGeLaToR schreef op zaterdag 03 augustus 2013 @ 10:22:
[...]


Iemand nog een suggestie op deze? Tot op heden nog niet op weten te lossen helaas.

Maak eens test.php aan, en zet daar het volgende in:

PHP:

<?php
phpinfo();
?>

Staat daar mysql of mysqli ingeschakeld?

[NiGeLaToR]

xost schreef op zaterdag 03 augustus 2013 @ 10:42:
[...]


Maak eens test.php aan, en zet daar het volgende in:

PHP:

<?php
phpinfo();
?>

Staat daar mysql of mysqli ingeschakeld?

Kom ik op terug, ga het later vandaag plaatsen (kan er nu niet bij). Thx voor meedenken!

[Mirx_NL]

Heeft met je path settings te maken volgens mij. Is bij handmatige installatie ook.
Even /usr/bin/php gebruiken ipv php zelf.


Meterkast> php retrieve.php
PHP Fatal error: Call to undefined function mysql_connect() in /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php on line 27
Meterkast> /usr/bin/php retrieve.php
Last retrieve at Sat Aug 3 14:02:11 2013

[ Voor 5% gewijzigd door Mirx_NL op 03-08-2013 14:11 ]

[kgb545]

xost schreef op vrijdag 02 augustus 2013 @ 17:19:
Ik word gek ik ben niet zo'n linux held, en laatst was de upgrade naar Ubuntu server 12.10 niet helemaal goed gegaan. Apache2 en PHP opnieuw geinstalleerd en alles lijkt weer te werken maar alle Sickbeard en Couchpotato kunnen niet meer zoeken via Spotweb (via Newznab).

Spotweb is te benaderen via http://10.0.0.2/spotweb en dat werkt prima (spotweb staat in /var/www/spotweb)

De API doet het ook, ik kan namelijk naar http://10.0.0.2/api en naar http://10.0.0.2/spotweb/api en dan krijg ik netjes een XML foutcode met "Missing parameter".

<knip>

Dit probleem heb iki ook gehad. Ik heb dit op kunnen lossen door de "rewrite" optie te enablen in de Apache2 server. Ik gebruik zelf Webmin om dit aan te passen, ik zou niet weten hoe je dat via een shell in linux zoumoeten doen. Maar via google is dat vast wel te vinden

Volgens mij moet dit enabled worden, omdat spotweb via een .htaccess file het api adres rewrite.

[remcoXP]

Ik gebruik nu de refactor build en ik krijg in sickbeard het volgende:

Ik draai nu spotweb refactored en krijg in sickbeard (die van tpb schumi) de volgende melding:

2013-07-27 22:52:57.079123 SEARCHQUEUE-MANUAL-SEARCH :: Error trying to load Spotweb RSS feed: syntax error: line 2, column 0
2013-07-27 23:07:39.167977 SEARCHQUEUE-BACKLOG-257655 :: Error trying to load Spotweb RSS feed: syntax error: line 2, column 0

wat kan ik hieraan doen? mijn api werkt, maar ik kan niet achterhalen wat dit nu is.

[WoBBeL]

kgb545 schreef op zaterdag 03 augustus 2013 @ 15:57:
[...]


Dit probleem heb iki ook gehad. Ik heb dit op kunnen lossen door de "rewrite" optie te enablen in de Apache2 server. Ik gebruik zelf Webmin om dit aan te passen, ik zou niet weten hoe je dat via een shell in linux zoumoeten doen. Maar via google is dat vast wel te vinden

Volgens mij moet dit enabled worden, omdat spotweb via een .htaccess file het api adres rewrite.

Dat werkte wel, anders zou ik een 404 moeten krijgen (immers, de API kan niet gevonden worden). Probleem zat in database, erg vreemd

[Koffie]

Ik heb spotweb draaien op mijn Qnap. Deze installatie is vrij recent, hiervoor draaide ik het op een Ubuntu server.
Bij de installatie op de qnap heb ik mijn bestaande spotweb database geimporteerd op de MySQL server. Zo verder geen enkel probleem.

Nu hoor ik vandaag een collega roepen dat een bepaalde film gepost was (toen al een age van 13 uur). Het vreemde was: bij mij stond hij niet in de database.
Pas laat in de middag begin ik de film binnen te krijgen in mijn database, maar nog steeds niet alle meldingen (hij staat namelijk ook in de categorie HD, en daar heb ik nog niets).
Het is dus niet een fout met zoeken oid, want posts in andere categorieën zag ik vanochtend nog niet en inmiddels wel.
Normaal zou je denken aan retentie van je provider oid, maar in dit specifieke geval gebruiken de collega's en ik exact dezelfde usenet provider, sterker nog: zelfs hetzelfde account.

Spotweb zelf vind overigens dat hij up2date is, ook nadat ik meerdere malen vanaf een SSH sessie een retrieve draai.

Iemand een idee in welke hoe ik dit moet zoeken?