SpotWeb - Webbased Spotnet - deel 2

@Paul.tjuh1986

Failed to set permission for /volume2/Series/SERIENAAM to 777

Check je rechten even in de map Series. Sickbeard wil deze aanpassen naar 777 mag kan / mag dit niet.

quote:

Paul.tjuh1986 schreef op dinsdag 31 januari 2012 @ 23:10:
[..]
Sickbeard zegt het volgende:
[..]

Verkeerde topic, dit is niet voor SickBeard

quote:

psvjw schreef op dinsdag 27 december 2011 @ 16:31:
Heel vaag. Elke dag als ik Spotweb opstart, vraagt hij me om Ownsettings.php weer te wijzigen. Maar dat heb ik nu al een week lang elke dag gedaan. Ik sla hem op en de melding verdwijnt. De dag erop weer dezelfde melding zie:
code:

There is an error in your ownsettings.php

Please remove nntp_nzb has been removed from ownsettings.php
nzbhandling has become an user preference
show_updatebutton has become an user right
from your 'ownsettings.php' file, this setting is set in the settings panel from within Spotweb itself

Afgelopen week niet op Spotweb ingelogd en *plop*

Daar heb ik mijn zelfde melding weer.

Het lijkt er op dat hij telkens een oude ownsettings.php terug zet, maar ik heb geen idee hoe of waar ik zou moeten checken

Spotweb is nu eindelijk de boel aan t updaten.
Mijn kennis van een console is alweer een 12 jaar oud (unix en de cmd van dos) dus was weer even puzzelen.
(niet echt mijn hobby)

Het heeft nogal wat voeten in aarde gehad. Ik gebruikte eerst een versie voor mijn nas, qnap. Maar daarin kon ik niet zoeken, dus een git pull gedraait. Vervolgens kon ik niet meer inloggen, na het invoeren van naam en pw bleef het schermpje gewoon staan en geneurde er niks. Dus even de users weggegooid en de upgrade-db weer gedraait, natuurlijk vergeten dat alles aan de userid hangt, dus waren al mn filters weg... Dat weer hersteld, etc, kon nog steeds niet inloggen.
Vervolgens een zip van github gedownload, maar daar kreeg ik steeds de melding dat ik de upgrade-db.php moest draaien! Die melding verdween dus niet na het updaten. Dus even de db leeg geknikkerd en weer de upgrade gedraait.
En zo ging het maar door.

Nu draai ik weer een versie via git pull en kan ik weer inloggen. Nu maar hopen dat de nzbknop werkt, want die zie ik alleen in de mobiele variant, maar loopt vast. Wellicht door de oude posts.

Ik laat het nog maar even door draaien en zien we later wel verder.
Het lijkt me serieus prachtig als alles werkt, maar plug en play is het nog niet echt

Ik ga later e.e.a. Nog even aanpassen zodat ik de volledige site zie op mn ipad, maar dat is van latere zorg.

quote:

SSoaker schreef op zondag 18 december 2011 @ 10:28:
Een nieuwe pull loste bovenstaand probleem voor mij op.

Maar bij mij werkt de retreive.php niet meer:
> /usr/bin/php retrieve.php
Last retrieve at Sun Dec 18 10:20:47 2011
Retrieving new Spots from server textnews.eweka.nl...
Looking for articlenumber for messageid
Searching from 3131275 to 3136276
Appr. Message count: 2532350
First message number: 603926
Last message number: 3136276
Current message: 3135558

Retrieving 3135558 till 3136277PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 103345944 bytes) in /volume1/web/spotweb/lib/SpotNntp.php on line 292

Opgelost PHP memory limit aan te passen mbv edit van /usr/syno/etc/php.ini

Bedankt voor de tip, dit probleem had ik dus ook. Ik ken mn weg nog niet zo hier, dus dit was waardevol.
Ik gebruik een qnap, dus daar is het pad: /mnt/HDA_ROOT/.config/php.ini (voor andere mensen die een qnap hebben)
Je kunt dit tevens aanpassen in het onderhoudsscherm van qnap bij de webserver (php.ini)

Edit
Het probleem is nog niet opgelost, ik krijg nog steeds dat memory probleem, ondanks dat ik em verhoogd heb naar 128/256. Het lijkt op probleem 529 alleen heb ik al een git pull gedaan en geeft aan dat ik de laatste versie heb. Iemand enig idee?

Edit2
Maar weer een git clone gedaan, mijn versie van retrieve.php kwam niet overeen met die uit de laatste zip

Edit3
En die update de database niet na een retrieve.php --force
Zo blijf je bezig...

Edit4
De database maar eens weggegooid en opnieuw laten maken door upgrade-db.
Alles weer opnieuw ingesteld, maar weer wordt de database niet bijgewerkt, volgens phpMyAdmin.
De spots-tabel blijft leeg, en nowrunning/lastrun staan beide op 0

Edit5
Te ongeduldig geweest, laatste git clone werkte prima, maar duurde even totdat de juiste posts in de db geladen werden.

rinkel wijzigde dit bericht 02-02-2012 14:10 (25%)

Gisteren weer ff een update gedaan. Nu spijt van.
De rechten webinterface werkt niet echt lekker maar daar kom ik nog wel overheen.
Helaas werkt het updaten van de database niet meer. Ik krijg onderstaande melding:

[code]
PHP Fatal error: Call to undefined function curl_init() in /var/www/spotweb/lib/SpotsOverview.php on line 414
[/code]

Ik heb nogmaals een git-pull uitgevoerd maar dit lost niets op.

Iemand?



Nevermind: Ik heb php5-curl module geïnstalleerd en daarna werkt het wel

MrDry wijzigde dit bericht 03-02-2012 12:18 (9%)

quote:

psvjw schreef op woensdag 01 februari 2012 @ 11:57:
[...]


Afgelopen week niet op Spotweb ingelogd en *plop*

Daar heb ik mijn zelfde melding weer.

Het lijkt er op dat hij telkens een oude ownsettings.php terug zet, maar ik heb geen idee hoe of waar ik zou moeten checken

Iemand een idee?

Hoe kan er via Spotweb v0.54.19.27 een aflevering van een serie gespot worden met als bron TV?
Zie alleen de keuze Cam, R5, Retail, Telesync.

Spotnet 1.7.4 heeft de mogelijkheid als bron TV te kiezen en Spotnet 1.7.6 heeft de mogelijkheid niet meer.
Doe het spotten liever niet via verschillende programma's.

Een oude Spotweb versie gebruiken lijkt mij ook geen oplossing.

qwerty_running wijzigde dit bericht 04-02-2012 00:04 (5%)

*knip* never mind, ik zat dus naar usergroup 1 te kijken ipv usergroup 2

//edit

Een andere vraag die wel open staat:
Mijn admin-user heeft de knop "Spot toevoegen" niet. Hoe krijg ik die functionaliteit ook ingeschakeld voor mijn admin-user?

woest85 wijzigde dit bericht 04-02-2012 03:53 (139%)

Je kan niet posten met een van de builtin accounts. Makkelijkste is dus om een nieuwe Spotweb account te maken en die in dezelfde groepen te zetten als de ingebouwde admin account.

Sinds dat ik openssl enabled heb via php.ini ziet mijn testinstall.php er zo uit:

OpenSSL
At least 1 of these must be OK
these modules are sorted from fastest to slowest
openssl OK
gmp NOT OK
bcmath OK
Can create private key? NOT OK

Als ik openssl uitzet dan staat er bij private key wel OK
Iemand toevallig een oplossing?

Ik heb op mijn Synology 1511+ wat issues met installeren. Alles lijkt goed te gaan tot aan de upgrade-db.php stap. Als ik dit uit voer krijg ik het volgende terug:


NAS> /usr/bin/php upgrade-db.php
Updating schema..(mysql)


SpotWeb crashed

Database schema of settings upgrade mislukt:
Table 'information_schema.key_column_usage' doesn't exist


#0 /volume1/web/spotweb/lib/dbeng/dbeng_abs.php(92): dbeng_mysql->rawExec('SELECT CONSTRAI...')
#1 /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php(82): dbeng_abs->exec('SELECT CONSTRAI...', Array)
#2 /volume1/web/spotweb/lib/dbstruct/SpotStruct_mysql.php(262): dbeng_mysql->arrayQuery('SELECT CONSTRAI...')
#3 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(259): SpotStruct_mysql->dropForeignKey('spotsfull', 'messageid', 'spots', 'messageid', 'ON DELETE CASCA...')
#4 /volume1/web/spotweb/lib/SpotUpgrader.php(53): SpotStruct_abs->updateSchema()
#5 /volume1/web/spotweb/upgrade-db.php(29): SpotUpgrader->database()
#6 {main}NAS>

Iemand dit al eens eerder aan de hand gehad?

quote:

elevator schreef op zaterdag 04 februari 2012 @ 07:55:
Je kan niet posten met een van de builtin accounts. Makkelijkste is dus om een nieuwe Spotweb account te maken en die in dezelfde groepen te zetten als de ingebouwde admin account.

Ok, bij deze maar gedaan dan. Jammer dat de builtin accounts dit niet kunnen.

Your current Spotweb installation is tooo old to be upgraded to this current version of Spotweb.
Please download an earlier version of Spotweb (https://github.com/spotwe...e81218271dc584a858f6916af)

Na een git pull krijg ik deze melding bij de upgrade db...

Na het downloaden van de zipball (safari pakt het direct uit naar een mappie) gooi ik deze op de locatie van mijn oude spotweb, kopieer ownsettings, en draai upgrade db.
Is dit de correcte wijze of kan ik iets met git doen??

Het is namelijk zo dat ik erachter kwam dat door het commit ID achter zipball/ te plaatsen alle commits te downloaden zijn. Zodoende ben ik zo ver terug gegaan als juni vorig jaar om upgrade db's uit te voeren, maar iedere keer met bovenstaande melding geconfronteerd.

Heb het idee dat er iets met een Git gedaan moet worden waardoor die versie ook geregistreerd wordt ergens ipv een mappie kopiëren??

Krijg je steeds dezelfde commitnummer me de vraag om die upgrade-db uit tevoeren?

hij doetut niemeer

quote:

Updating schema..(mysql)
Validating spots(messageid)
Validating spots(poster)


SpotWeb crashed

Database schema of settings upgrade mislukt:
Invalid collation setting for varchar: utf8_general_ci


#0 /home/web/spotweb/lib/dbstruct/SpotStruct_abs.php(150): SpotStruct_mysql->getColumnInfo('spots', 'poster')
#1 /home/web/spotweb/lib/dbstruct/SpotStruct_abs.php(135): SpotStruct_abs->compareColumn('poster', 'spots', 'VARCHAR(128)', NULL, false, 'utf8')
#2 /home/web/spotweb/lib/dbstruct/SpotStruct_abs.php(322): SpotStruct_abs->validateColumn('poster', 'spots', 'VARCHAR(128)', NULL, false, 'utf8')
#3 /home/web/spotweb/lib/SpotUpgrader.php(53): SpotStruct_abs->updateSchema()
#4 /home/web/spotweb/upgrade-db.php(29): SpotUpgrader->database()

quote:

Webjunkie schreef op dinsdag 07 februari 2012 @ 07:50:
hij doetut niemeer


[...]

Updaten!
Collation was not properly checked between upgrades

:/var/www/spotweb$ sudo git pull
Already up-to-date.
code:

        Validating spotsfull(fullxml)


SpotWeb crashed

Database schema of settings upgrade mislukt:
   Invalid collation setting for varchar: utf8_general_ci


#0 /var/www/spotweb/lib/dbstruct/SpotStruct_abs.php(150): SpotStruct_mysql->getColumnInfo('spotsfull', 'fullxml')
#1 /var/www/spotweb/lib/dbstruct/SpotStruct_abs.php(135): SpotStruct_abs->compareColumn('fullxml', 'spotsfull', 'TEXT', NULL, false, 'utf8')
#2 /var/www/spotweb/lib/dbstruct/SpotStruct_abs.php(348): SpotStruct_abs->validateColumn('fullxml', 'spotsfull', 'TEXT', NULL, false, 'utf8')
#3 /var/www/spotweb/lib/SpotUpgrader.php(53): SpotStruct_abs->updateSchema()
#4 /var/www/spotweb/upgrade-db.php(29): SpotUpgrader->database()
#5 {main}

Ik heb dit ook op github gezet als commentaar op de merge van MassD67, maar ik weet niet hoe ik het issue terug moet openen.

Ik heb dezelfde foutmelding: Invalid collation setting for varchar: utf8_general_ci

De aangegeven wijzigingen van Nightspirit zitten erin:
code:

        # Chcek character set setting
        if ((strtolower($q['COLLATION_NAME']) != $collation) && ($q['COLLATION_NAME'] != null)) {
            # var_dump($q);
            # var_dump($collation);
            # die();
            return 'charset';
        } # if

Enig idee?

Heb die foutmelding ook na de laatste git update.
Een beetje op de gok wat geprobeerd. In de database gekeken naar de tabel 'spots', en specifiek naar het veld 'poster', gezien die 2 in de foutmelding stonden. Dit veld stond hier op 'utf8_general_ci', een aantal andere velden stond op 'ascii_general_ci'.

Gezien de fout "Invalid collation setting for varchar: utf8_general_ci" zal hij die utf8 om één of andere reden niet lief vinden. De collation van dit veld op 'ascii_general_ci' gezet. (En dat duurt best lang..)

Table spots has been altered successfully
SQL:

1	ALTER TABLE  `spots` CHANGE  `poster`  `poster` VARCHAR( 128 ) CHARACTER SET ASCII COLLATE ascii_general_ci NULL DEFAULT NULL

Nu nog een keer upgrade-db.php aan het draaien, en ik kom iig al 1 stap verder:
Modifying column poster (charset) on spots

Waarschijnlijk gaat dit ook heel lang duren, dus ik zie wel wat het gaat worden. En of het uberhaupt goed is wat ik nu gedaan heb Heb er verder geen verstand van.

Mijn NAS is druk bezig zie ik, op momenten zoals dit kom je dan wel wat CPU power tekort

CPU: 99.8% usr 0.1% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 2.05 2.24 1.84 2/202 14107

Edit:
Zo te zien is het veld spots.poster nu omgezet naar utf8_unicode_ci, en ik crash nu een stukje verder:

quote:

Validating spots(title)

SpotWeb crashed

Database schema of settings upgrade mislukt:
Invalid collation setting for varchar: utf8_general_ci

Dus ik ga spots.title eens omzetten, nu direct naar utf8_unicode_ci, kijken of dat helpt.
Edit: Die is nu ook klaar, upgrade-db.php gaat gelijk door naar de volgende foutmelding, dus direct omzetten naar utf8_unicode_ci was een goed idee
Nu de volgende omzetten: spots.tag.
Dat is, in de tabel spots, volgens mij de laatste. Ben benieuwd.

Nog meer edit:
Kom wel steeds iets verder, maar blijf wel van fout naar fout gaan.
Net is upgrade-db.php zelf een behoorlijke tijd bezig geweest met spots.spotterid om te zetten van ascii_general_ci naar ascii_bin.
Toen hij daar uiteindelijk mee klaar was ging ik verder naar de volgende fout Hij liep nu vast op spotsfull.fullxml. Ik heb (gelukkig?) geen full spots, dus daar was ik zo mee klaar.
upgrade-db.php loopt nu weer, en dit gaat volgens mij een zware worden:

quote:

Adding column stamp(UNSIGNED INTEGER) to commentsxover

Nakebod wijzigde dit bericht 07-02-2012 12:01 (46%)

Spotweb is op Github momenteel en heeft een nieuwe RLS klaar gezet, ik heb die nu gepulled en ben nu mijn DB aan het upgraden...

quote:

X-DraGoN schreef op dinsdag 07 februari 2012 @ 12:50:
Spotweb is op Github momenteel en heeft een nieuwe RLS klaar gezet, ik heb die nu gepulled en ben nu mijn DB aan het upgraden...

Kan je dit voor een leek vertalen?

quote:

wopper schreef op dinsdag 07 februari 2012 @ 12:58:
[...]


Kan je dit voor een leek vertalen?

De release waar ik naar linkte werkte niet. Er staat nu een nieuwe release klaar die voor meerdere mensen wel werkt. Even updaten en upgrade-db zou geen probleem meer moeten zijn

Haha okey,

kan je aangeven hoe je kunt updaten als je de LaSi scripts gebruikt op je Synology, of heb je een handmatige variant ergens beschikbaar want dat moet met mijn linux kennis ook lukken?

quote:

Nightspirit schreef op dinsdag 07 februari 2012 @ 08:38:
[...]

Updaten!
Collation was not properly checked between upgrades

natuurlijk gedaan.
waarom zou ik anders upgrade-db draaien

quote:

X-DraGoN schreef op dinsdag 07 februari 2012 @ 12:50:
Spotweb is op Github momenteel en heeft een nieuwe RLS klaar gezet, ik heb die nu gepulled en ben nu mijn DB aan het upgraden...

hij 's hier nu ook (al vrij lang) bezig.
tot op heden nog geen errors.

Webjunkie wijzigde dit bericht 07-02-2012 14:07 (31%)

quote:

Webjunkie schreef op dinsdag 07 februari 2012 @ 14:06:
hij 's hier nu ook (al vrij lang) bezig.
tot op heden nog geen errors.

Bij mij is hij ook nog steeds bezig...

hier heeft het een dikke half uur geduurd (op een i3) , maar het resultaat mag er wezen.
hij doetut weer

quote:

X-DraGoN schreef op dinsdag 07 februari 2012 @ 14:15:
[...]


Bij mij is hij ook nog steeds bezig...

Nu heeft hij gedaan... op een P4 1.7 Ghz, ik heb het vermoeden dat het niet veel te maken heeft met de CPU, maar meer met de disk waarop het staat, aangezien de load tijdens aanpassing rond de 30% bleef hangen.

Meer mensen die problemen hebben om op een mobiel apparaat in te loggen.
Zodra ik wil inloggen gebeurt er verder niet behalve dat mijn browser naar deze link gaat:
code:

**urlnaarspotweb**/?page=login&data[htmlheaderssent]=true

quote:

X-DraGoN schreef op dinsdag 07 februari 2012 @ 15:21:
[...]


Nu heeft hij gedaan... op een P4 1.7 Ghz, ik heb het vermoeden dat het niet veel te maken heeft met de CPU, maar meer met de disk waarop het staat, aangezien de load tijdens aanpassing rond de 30% bleef hangen.

Hier al de hele middag bezig op een p-mobile 1.7Ghz (gaat ook braaf op 800Mhz draaien omdat ie niets te doen heeft...), maar de schijf waarop het draait doet max 33MB/s , heb in die tabel ~1,340,000 records... the horror

woest85 wijzigde dit bericht 07-02-2012 17:48 (6%)

Ik heb even gegoogled op deze error en het enige wat ik hierover kan vinden is dat de Tabel information_schema pas beschikbaar is in versie 5.x van MYSQL. Op de synology draait mysql nog op versie 4.x. Dat is vreemd want volgens de synology support site zou mysql V 5.1.49 geinstalleerd moeten zijn, maar het is toch echt 4.1.22

mysql> SHOW VARIABLES LIKE "%version%";
+-------------------------+-------------------------------+
| Variable_name | Value |
+-------------------------+-------------------------------+
| protocol_version | 10 |
| version | 4.1.22 |
| version_comment | optware distribution 4.1.22-3 |
| version_compile_machine | i686 |
| version_compile_os | pc-linux-gnu |
+-------------------------+-------------------------------+
5 rows in set (0.00 sec)

quote:

netvista schreef op zaterdag 04 februari 2012 @ 10:54:
Ik heb op mijn Synology 1511+ wat issues met installeren. Alles lijkt goed te gaan tot aan de upgrade-db.php stap. Als ik dit uit voer krijg ik het volgende terug:


NAS> /usr/bin/php upgrade-db.php
Updating schema..(mysql)


SpotWeb crashed

Database schema of settings upgrade mislukt:
Table 'information_schema.key_column_usage' doesn't exist


#0 /volume1/web/spotweb/lib/dbeng/dbeng_abs.php(92): dbeng_mysql->rawExec('SELECT CONSTRAI...')
#1 /volume1/web/spotweb/lib/dbeng/dbeng_mysql.php(82): dbeng_abs->exec('SELECT CONSTRAI...', Array)
#2 /volume1/web/spotweb/lib/dbstruct/SpotStruct_mysql.php(262): dbeng_mysql->arrayQuery('SELECT CONSTRAI...')
#3 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(259): SpotStruct_mysql->dropForeignKey('spotsfull', 'messageid', 'spots', 'messageid', 'ON DELETE CASCA...')
#4 /volume1/web/spotweb/lib/SpotUpgrader.php(53): SpotStruct_abs->updateSchema()
#5 /volume1/web/spotweb/upgrade-db.php(29): SpotUpgrader->database()
#6 {main}NAS>

Iemand dit al eens eerder aan de hand gehad?

netvista wijzigde dit bericht 08-02-2012 11:29 (26%)

ik wil een tweede gebruiker toevoegen welke zelf filters kan aanmaken, maar ik kan "add user" klikken en de 4 velden invullen, op het moment dat je op save drukt krijg je de melding "password to short"

Maar in het add user popup-je zit geen password field, hoe werkt dat normaal of is dit een bug?

Iemand had mij gevraagd (via dm maar die kan ik niet meer vinden of in een topic) om deze plugin: https://github.com/TsUPeR/xbmc-newznab geschikt te maken voor spotweb omdat ik de nzb.su plugin daarvan geschikt had gemaakt voor newznab. Nu is dat een mooie kans om python onder de knie te krijgen. Alleen, het betreft voornamelijk sloopwerk (cart enzo moet eruit omdat spotweb dat niet heeft) en sommige links moeten wat aangepast worden.

Ik ben druk met andere python dingetjes dus kan me hier niet goed op concentreren. Misschien dat iemand anders met scriptervaring hier even een uurtje op kan blind staren en de boel om kan zetten?

De addon.xml moet ook aangepast worden en natuurlijk het logo, aangezien de spotweb plugin in xmbc niet met de newznab-plugin zou moeten conflicteren.

Ik ben ook bezig om spotweb werkend te krijgen op mijn NAS, maar ik loop tegen een probleem aan met het retrieve.php script.

Ik heb alle voorbereidingen uitgevoerd en dat lijkt allemaal in orde. Ook via de testinstall.php krijg ik te zien dat alles in orde is. Ik kan ook inloggen op spotweb en mijn newsserver invullen.

Dus... nu alleen de spots ophalen toch???

nou daar gaat het dus mis. Als ik het script aanroep krijg ik het volgende:


Last retrieve at Thu 01 Jan 1970 01:00:00 AM CET
Retrieving new Spots from server news.lightningusenet.com...
Illegal instruction

en hij kapt er gelijk mee.

Weet iemand wat hier aan de hand is?

Ik zou graag een aantal genres van een bepaalde categorie uit de database willen verwijderen, om ruimte te besparen. Ik heb bijv. toch geen Xbox, Playstation of Nintendo, dus die onderdelen zouden allemaal weg mogen. Ik heb al op de wiki gekeken naar de handige query's, maar die lijkt niet meer up to date te zijn.

Het lijkt erop dat de cache tabel is aangepast en krijg ik bij deze regel:
code:

LEFT JOIN cache ON spots.messageid=cache.messageid

een foutmelding. (#1054 - Unknown column 'cache.messageid' in 'on clause')

Iemand enig idee wat nu wel de goede manier is om spots te verwijderen uit de database?

@Dr_Hell: Wat SQL zegt is feitelijk dat de kolom messageid in tabel cache niet meer bestaat, wellicht heet die nu dus anders. Andere naam opzoeken met bijvoorbeeld phpMyAdmin en you're good to go.

Is er trouwens een manier om de tabel commentsxover te schonen? Ik kan opzich truncate doen, maar dan lijkt het wel alsof de server gaat hangen, is het mogelijk om dat stapsgewijs te doen en daarna pauze te houden of iets te bufferen of iets dergelijks? Ik hou namelijk graag van een lichte Spotweb database en comments worden bij mij pas opgehaald met de spot.

CptChaos wijzigde dit bericht 09-02-2012 23:09 (49%)

Die kolom bestaat idd niet, dat was wel duidelijk
Alleen wat nog niet duidelijk is, is welke kolom ik dan wel moet hebben? Ik kan in de cache tabel geen kolom vinden die de message-id's bevat. Wel timestamps en andere "metadata", maar geen message-id's.

Is het verstandig om dan maar niks uit de cache tabel te verwijderen? Dus gewoon die regel uit de opdracht verwijderen?

Je kan volgens mij ook heel de cache tabel gewoon weggooien (dat doet een van de upgrade-db's ook, dus ik denk dat dat gewoon kan)

quote:

wopper schreef op woensdag 08 februari 2012 @ 20:21:
ik wil een tweede gebruiker toevoegen welke zelf filters kan aanmaken, maar ik kan "add user" klikken en de 4 velden invullen, op het moment dat je op save drukt krijg je de melding "password to short"

Maar in het add user popup-je zit geen password field, hoe werkt dat normaal of is dit een bug?

Ik heb hetzelfde probleem

Ik krijg voortdurend de volgende melding bij het uitvoeren van retrieve.php

quote:

Calculating how many spots are new
Fatal error: Maximum execution time of 2400 seconds exceeded in *******\lib\dbeng\dbeng_mysql.php on line 42

De 2400 seconds is juist omdat ik dit in SpotsOverview.php al verhoogd heb van de standaar 960.

Wat is de oorzaak ervan dat dit niet goed gaat? Als ik meer info aan moet leveren hoor ik het uiteraard graag.

woest85 wijzigde dit bericht 10-02-2012 12:33 (4%)

quote:

wopper schreef op woensdag 08 februari 2012 @ 20:21:
ik wil een tweede gebruiker toevoegen welke zelf filters kan aanmaken, maar ik kan "add user" klikken en de 4 velden invullen, op het moment dat je op save drukt krijg je de melding "password to short"

Maar in het add user popup-je zit geen password field, hoe werkt dat normaal of is dit een bug?

Iemand nog een idee want krijg er nu geen tweede gebruiker bij

Hmmm lijkt een bugje na 2x drukken voegt hij hem toe met een zelf gekozen wachtwoord. De eerste keer heb je geen veld om een wachtwoord te kiezen dus hij vindt zijn eigen gekozen wachtwoord te kort

Is geen bug. Je krijgt na het aanmaken van het account het gegenereerde wachtwoord te zien. Als je de beschikking hebt over een mailserver kun je gewoon een mail versturen naar het e-mailadres die bij de gebruiker hoort. Die logt er vervolgens mee in en dan kan de gebruiker gewoon zelf het wachtwoord wijzigen. Zie niet wat er bug aan is.

Nou ja als ik niet zelf het wachtwoord in kan vullen in krijg na het klikken direct deze melding lijkt me dat een beetje buggie toch?

Het draait op een Synology dus na nogmaals klikken 1 of 2x verschijnt wel het groene scherm met de toegevoegde gebruiker en het gegenereerde password.

quote:

Gerard v.d. Horst schreef op donderdag 09 februari 2012 @ 17:45:
Ik ben ook bezig om spotweb werkend te krijgen op mijn NAS, maar ik loop tegen een probleem aan met het retrieve.php script.

Ik heb alle voorbereidingen uitgevoerd en dat lijkt allemaal in orde. Ook via de testinstall.php krijg ik te zien dat alles in orde is. Ik kan ook inloggen op spotweb en mijn newsserver invullen.

Dus... nu alleen de spots ophalen toch???

nou daar gaat het dus mis. Als ik het script aanroep krijg ik het volgende:


Last retrieve at Thu 01 Jan 1970 01:00:00 AM CET
Retrieving new Spots from server news.lightningusenet.com...
Illegal instruction

en hij kapt er gelijk mee.

Weet iemand wat hier aan de hand is?

Kun je nog wel downloaden via lightningusenet. Bij mij was deze week het account niet meer te gebruiken ondanks dat ik nog voldoende dagen over had voor mijn account. Helaas is het afgelopen met deze partij.

Check dus eerst even of je met bv grabit nog wel met dit account iets kunt downloaden.

quote:

Dr_Hell schreef op vrijdag 10 februari 2012 @ 10:55:
Die kolom bestaat idd niet, dat was wel duidelijk
Alleen wat nog niet duidelijk is, is welke kolom ik dan wel moet hebben? Ik kan in de cache tabel geen kolom vinden die de message-id's bevat. Wel timestamps en andere "metadata", maar geen message-id's.

Is het verstandig om dan maar niks uit de cache tabel te verwijderen? Dus gewoon die regel uit de opdracht verwijderen?

Ik heb ondertussen een berg spots verwijderd, met een kleine aanpassing op de query zoals die op de wiki te vinden is. Ik heb niets uit de cache tabel verwijderd en alles lijkt nog steeds goed te werken

Wat me opvalt is dat soms als je een filter opent het een hele tijd duurt voordat die geladen is. Vooral als je een filter opent die amper wordt gebruikt.. Als ik bijv. de standaard HD filter 1x in de maand open duurt dat zo een minuut voor die geladen is. Heeft dit met optimalisatie te maken?

quote:

robbinonline schreef op dinsdag 07 februari 2012 @ 17:39:
Meer mensen die problemen hebben om op een mobiel apparaat in te loggen.
Zodra ik wil inloggen gebeurt er verder niet behalve dat mijn browser naar deze link gaat:
code:

**urlnaarspotweb**/?page=login&data[htmlheaderssent]=true

Schopje

quote:

MikeOO schreef op zaterdag 11 februari 2012 @ 07:35:
[...]


Kun je nog wel downloaden via lightningusenet. Bij mij was deze week het account niet meer te gebruiken ondanks dat ik nog voldoende dagen over had voor mijn account. Helaas is het afgelopen met deze partij.

Check dus eerst even of je met bv grabit nog wel met dit account iets kunt downloaden.

Ik heb totaal geen probleem met lightningusenet. Behalve dan dat je niet meer kan verlengen...
Mijn download gaat zo snel als mijn verbinding toe laat.

Het probleem is ondertussen ook gevonden. Het is een bug in de php versie.

hee allemaal,

Ik heb mijn spotweb opnieuw geinstalleerd, dit keer op een Ubuntu systeem.
Ik heb het geheel via het LaSi.sh script geinstalleerd, echter krijg ik nu de volgende foutmelding bij het runnen van retrieve.php, waardoor deze telkens vast loopt.

Ik heb al wel gegoogled, maar de oorzaken van de spontane mysql reboot zijn zo ongeloofelijk breed, ik kon hier geen juiste oplossing uit destileren.
Heeft iemand hier ervaring mee?

quote:

Retrieving 551332 till 552333

SpotWeb v0.56.20.27 on PHP v5.3.6-13ubuntu3.5 crashed

Fatal error occured retrieving reports:
Lost connection to MySQL server during query


#0 /var/www/spotweb/lib/dbeng/dbeng_abs.php(92): dbeng_mysql->rawExec('SELECT messagei...')
#1 /var/www/spotweb/lib/dbeng/dbeng_mysql.php(82): dbeng_abs->exec('SELECT messagei...', Array)
#2 /var/www/spotweb/lib/SpotDb.php(840): dbeng_mysql->arrayQuery('SELECT messagei...')
#3 /var/www/spotweb/lib/retriever/SpotRetriever_Comments.php(92): SpotDb->matchCommentMessageIds(Array)
#4 /var/www/spotweb/lib/retriever/SpotRetriever_Abs.php(167): SpotRetriever_Comments->process(Array, 551332, 552333)
#5 /var/www/spotweb/lib/retriever/SpotRetriever_Abs.php(228): SpotRetriever_Abs->loopTillEnd(551332, '1000')
#6 /var/www/spotweb/retrieve.php(163): SpotRetriever_Abs->perform()
#7 {main}

Hm, ik heb een vreemd probleem gevonden toen ik wat eigen filters wou maken:

Ik gebruik de standaard layout, de spotcount die klopt dan gewoon.

Ik download de standaardfilters via 'Download je filters', de spotcount klopt nog steeds, upload ik deze weer ZONDER iets te wijzigen, dan klopt er van heel de spotcount niks meer

Het lijkt wel alsof het geexporteerde bestand niet in orde zou zijn, maar als ik deze open en de structuur binnenstebuiten keer lijkt alles gewoon te kloppen.

Klik op het aantal (er staat dan bijvoorbeeld 81682), dan krijg ik wel de 2 nieuwe spots te zien, en geen 81682.

Meer mensen die hier last van hebben?

/edit:
Nevermind, blijkbaar worden spotcounts gemaakt met de filters in gedachten; de filtercount tabel leeggegooid, 2x updaten en alles werkt naar behoren.

En niet vergeten je editor op UTF-8 te zetten, anders krijg je ook wat 'vreemde' resultaten.

LiquidSmoke wijzigde dit bericht 15-02-2012 10:32 (25%)

quote:

robbinonline schreef op dinsdag 07 februari 2012 @ 17:39:
Meer mensen die problemen hebben om op een mobiel apparaat in te loggen.
Zodra ik wil inloggen gebeurt er verder niet behalve dat mijn browser naar deze link gaat:
code:

**urlnaarspotweb**/?page=login&data[htmlheaderssent]=true

Ik heb hetzelfde probleem

MrOizo2005 wijzigde dit bericht 15-02-2012 16:40 (47%)

quote:

robbinonline schreef op zaterdag 11 februari 2012 @ 15:46:
[...]

Mobiele versie is stuk

Schopje

quote:

MrOizo2005 schreef op woensdag 15 februari 2012 @ 16:36:
[...]


Ik heb hetzelfde probleem

Zie github. Dit had ik al gemeld en men is niet van plan om dit op te korte termijn te maken.

Enige oplossing is de mobiele versie uit te zetten.. Zie wiki hoe je dat moet doen. Werk met mijn telefoon nu met de normale versie.. nogal omslachtig maar het is niet anders

Workaholic wijzigde dit bericht 15-02-2012 21:49 (31%)

Vandaag begonnen om Spotweb te installeren op mijn Ubuntu servertje. Na wat rotzooien heb ik het redelijk aan de praat. Nu nog even verdieen in de filters.

Het enige wat ik nog niet echt heb gevonden: links onder bij Maintenance staat bij mij : "Last update: onbekend". Ik dacht dat dit te maken had met de timezone (die nog niet ingesteld was). maar dit lijkt niet te werken.
Zou hier normaal een datum/tijd van de laatste retrieve.php update horen te staan? Want dat is wat ik eigenlijk verwacht, of moet ik die last update daarvan ergens anders terug vinden?

quote:

Koffie schreef op vrijdag 17 februari 2012 @ 21:34:
Vandaag begonnen om Spotweb te installeren op mijn Ubuntu servertje. Na wat rotzooien heb ik het redelijk aan de praat. Nu nog even verdieen in de filters.

Het enige wat ik nog niet echt heb gevonden: links onder bij Maintenance staat bij mij : "Last update: onbekend". Ik dacht dat dit te maken had met de timezone (die nog niet ingesteld was). maar dit lijkt niet te werken.
Zou hier normaal een datum/tijd van de laatste retrieve.php update horen te staan? Want dat is wat ik eigenlijk verwacht, of moet ik die last update daarvan ergens anders terug vinden?

Daar hoort te staan hoe lang het geleden is dat de laatste update is gedaan (weken, dagen, uren of wat dan ook).

Misschien hangt het samen met de nieuwe postcount? heb je dat toevallig uit staan?

Ik heb de hele bups weg gemikt en met git clone geïnstalleerd en nu werkt het wel

Ik wilde een retrieve doen na een git pull, maar hij vroeg om een upgrade, dus deed een upgrade, maar crashed toch. Zie hier beneden, wat moet ik nou doen om het weer werkend te krijgen??

Heel graag jullie hulp, heb geen idee wat te doen

synology nas ds 1511

quote ----------------
DiskStation> /usr/bin/php retrieve.php
Database schema is gewijzigd, draai upgrade-db.php aub
DiskStation> /usr/bin/php upgrade-db.php
Updating schema..(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)
Validating spots(reversestamp)
Validating spots(filesize)
Validating spots(moderated)
Validating spots(commentcount)
Validating spots(spotrating)
Validating spots(reportcount)
Validating spots(spotterid)
Validating spotsfull(messageid)
Validating spotsfull(verified)
Validating spotsfull(usersignature)
Validating spotsfull(userkey)
Validating spotsfull(xmlsignature)
Validating spotsfull(fullxml)
Validating nntp(server)
Validating nntp(maxarticleid)
Validating nntp(nowrunning)
Validating nntp(lastrun)
Validating nntp(serverdatelastrun)
Validating commentsxover(messageid)
Validating commentsxover(nntpref)
Validating commentsxover(spotrating)
Validating commentsxover(moderated)
Validating commentsxover(stamp)
Adding column stamp(UNSIGNED INTEGER) to commentsxover


SpotWeb crashed

Database schema of settings upgrade mislukt:
Duplicate column name 'stamp'


#0 /volume1/web/spotweb/lib/dbstruct/SpotStruct_mysql.php(174): dbeng_mysql->rawExec('ALTER TABLE com...')
#1 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(142): SpotStruct_mysql->addColumn('stamp', 'commentsxover', 'UNSIGNED INTEGE...', NULL, false, '')
#2 /volume1/web/spotweb/lib/dbstruct/SpotStruct_abs.php(367): SpotStruct_abs->validateColumn('stamp', 'commentsxover', 'UNSIGNED INTEGE...', NULL, false, '')
#3 /volume1/web/spotweb/lib/SpotUpgrader.php(53): SpotStruct_abs->updateSchema()
#4 /volume1/web/spotweb/upgrade-db.php(29): SpotUpgrader->database()
#5 {main}DiskStation>

Ik heb gisteren spotweb op een nieuwe ubuntu server geinstalleerd. Alles werkt prima, hij onthoudt alleen de instellingen voor NZB-afhandeling niet. Ik vul alles in voor sabnzbd, klik op wijzigen, en daarna is alles weer weg.
Ik heb de url goed (http://127.0.0.1:8181), de api-key klopt ook (geprobeerd met verschillende api-keys)
Kan het zijn dat er ergens schrijfrechten van een bestand/map niet goed staan? Of worden dit soort instellingen in de Mysql-database opgeslagen?
Kan iemand me verder helpen? Alvast bedankt.

Kan iemand mij uitleggen wat de verschillende settings voor retrieve.php betekenen?

Retrieve full spots
Prefetch images
Prefetch NZB files
Retrieve comments
Retrieve full comments
Retrieve reports

"Prefetch images" en "Prefetch NZB files" kan ik nog wel bedenken, maar wat is het verschil tussen "Retrieve comments" en "Retrieve full comments" ?

en als ik geen comments download, hoe kan ik die dan later toch wel zien (bij spotnet kun je op de comments klikken en dan worden ze alsnog gedownload).

• Full spots: Normaal halen Spotnet clients enkel de headers op. Voor onder andere de omschrijving en de afbeelding heb je de volledige spot nodig, deze wordt pas opgehaald als je een spot opent. Door deze setting aan te zetten haalt Spotweb altijd alle spots volledig op als je retrieve.php uitvoert. Maakt retrieve.php veel slomer maar Spotweb zelf weer sneller (mits je MySQL snel genoeg is).
• Prefetch images en Prefetch NZB files: Zelfde verhaal als hierboven maar dan voor de afbeeldingen en de NZB files.
• Retrieve comments: Comments worden ook geheaderd. Als je dit uitzet zal je nooit comments zien.
• Retrieve full comments: Zelfde verhaal als met fullspots. Dit maakt je database gigantisch groot, trouwens
• Retrieve reports: Als mensen een spot aanmelden als spam gebeurt dit ook door middel van een post in een nieuwsgroup. Spotweb kan deze reports ook ophalen en op die manier de reputatie van een spot weergeven zelfs voordat hij door de Spotnet moderators als spam/virus/etc gemarkeerd is.

Thanks voor je uitleg

Prefetch images & nzb files makat het trouwens nog groter. Hij cached dan _alle_ afbeeldingen dus dat maakt de database nog groter.

Hmm .. hoe zit dat nu met die comments dan? Ik heb de optie 'Retrieve comments' aanstaan, full comments niet.
Toch zie ik overal 0 comments. Hoe laat ik die dan ophalen?

quote:

w.d schreef op maandag 20 februari 2012 @ 08:13:
Ik heb gisteren spotweb op een nieuwe ubuntu server geinstalleerd. Alles werkt prima, hij onthoudt alleen de instellingen voor NZB-afhandeling niet. Ik vul alles in voor sabnzbd, klik op wijzigen, en daarna is alles weer weg.
Ik heb de url goed (http://127.0.0.1:8181), de api-key klopt ook (geprobeerd met verschillende api-keys)
Kan het zijn dat er ergens schrijfrechten van een bestand/map niet goed staan? Of worden dit soort instellingen in de Mysql-database opgeslagen?
Kan iemand me verder helpen? Alvast bedankt.

Ben je wel ingelogd met een user die rechten heeft om de instellingen te wijzigen?

quote:

oNo schreef op maandag 20 februari 2012 @ 14:23:
[...]

Ben je wel ingelogd met een user die rechten heeft om de instellingen te wijzigen?

Yep, ingelogd als admin...

quote:

w.d schreef op maandag 20 februari 2012 @ 08:13:
Ik heb gisteren spotweb op een nieuwe ubuntu server geinstalleerd. Alles werkt prima, hij onthoudt alleen de instellingen voor NZB-afhandeling niet. Ik vul alles in voor sabnzbd, klik op wijzigen, en daarna is alles weer weg.
Ik heb de url goed (http://127.0.0.1:8181), de api-key klopt ook (geprobeerd met verschillende api-keys)
Kan het zijn dat er ergens schrijfrechten van een bestand/map niet goed staan? Of worden dit soort instellingen in de Mysql-database opgeslagen?
Kan iemand me verder helpen? Alvast bedankt.

Klinkt mij als een browser screwup. Probeer het eens met alle addons uitgeschakeld.

Een probleem waar ik al vanaf begin installatie tegenaan loop: eens in de zoveel tijd is de HTML stuk
Ik heb het zojuist weer werkende gekregen door in IE alle browsing history te schonen, maar nog geen idee welke exactie optie het werkende maakte.
In Chrome heb ik ook, maar daar nog niet met opschonen kunnen testen.

Wanneer 'de HTML niet werkt' werkende de fancy dingen. SabNZB knop doet niets, search geeft geen uitklap menu en meestal komt de info/pagina van een aangeklikt spot onder de index pagina te staan (de index ligt dus letterlijk over de spot pagina.
Settings zien er ook niet uit:



In welke hoek zou ik dit moeten zoeken?

edit: een restart van Chrome lijkt te werken. Bij het sluiten van chrome word bijna alle browsing history behalve cookies verwijderd. Lijkt dus in die hoek te zitten.

Koffie wijzigde dit bericht 20-02-2012 16:48 (10%)

quote:

w.d schreef op maandag 20 februari 2012 @ 08:13:
Ik heb gisteren spotweb op een nieuwe ubuntu server geinstalleerd. Alles werkt prima, hij onthoudt alleen de instellingen voor NZB-afhandeling niet. Ik vul alles in voor sabnzbd, klik op wijzigen, en daarna is alles weer weg.
Ik heb de url goed (http://127.0.0.1:8181), de api-key klopt ook (geprobeerd met verschillende api-keys)
Kan het zijn dat er ergens schrijfrechten van een bestand/map niet goed staan? Of worden dit soort instellingen in de Mysql-database opgeslagen?
Kan iemand me verder helpen? Alvast bedankt.

Dit was een bug na een code aanpassing van gisteren. Zie ook github. Deze had ik gemeld end is vandaag opgelost.

quote:

Workaholic schreef op maandag 20 februari 2012 @ 22:01:
[...]


Dit was een bug na een code aanpassing van gisteren. Zie ook github. Deze had ik gemeld end is vandaag opgelost.

Thanks, ik ga gelijk pullen

Ik haal nu elke 10 minuten de updates binnen dmv een cron schedule van retrieve.php
Ik las op de mini wiki dat je bepaalde zooi uit de DB kunt verwijderen: https://github.com/spotweb/spotweb/wiki/Handige-query%27s
Het gaat mij specifiek om de porno die ik niet hoef.

Met deze query zou dat moeten lukken:

DELETE FROM spots, spotsfull, commentsxover, reportsxover, spotstatelist, reportsposted, cache USING spots
LEFT JOIN spotsfull ON spots.messageid=spotsfull.messageid
LEFT JOIN commentsxover ON spots.messageid=commentsxover.nntpref
LEFT JOIN reportsxover ON spots.messageid=reportsxover.nntpref
LEFT JOIN spotstatelist ON spots.messageid=spotstatelist.messageid
LEFT JOIN reportsposted ON spots.messageid=reportsposted.inreplyto
LEFT JOIN cache ON spots.messageid=cache.messageid
WHERE category = '0' and subcatz = 'z3|';

Is het gewoon een kwestie van deze query uitvoeren elke keer nadat retrieve.php heeft gedraaid?

quote:

Koffie schreef op woensdag 22 februari 2012 @ 09:03:
Ik haal nu elke 10 minuten de updates binnen dmv een cron schedule van retrieve.php
Ik las op de mini wiki dat je bepaalde zooi uit de DB kunt verwijderen: https://github.com/spotweb/spotweb/wiki/Handige-query%27s
Het gaat mij specifiek om de porno die ik niet hoef.

Met deze query zou dat moeten lukken:

DELETE FROM spots, spotsfull, commentsxover, reportsxover, spotstatelist, reportsposted, cache USING spots
LEFT JOIN spotsfull ON spots.messageid=spotsfull.messageid
LEFT JOIN commentsxover ON spots.messageid=commentsxover.nntpref
LEFT JOIN reportsxover ON spots.messageid=reportsxover.nntpref
LEFT JOIN spotstatelist ON spots.messageid=spotstatelist.messageid
LEFT JOIN reportsposted ON spots.messageid=reportsposted.inreplyto
LEFT JOIN cache ON spots.messageid=cache.messageid
WHERE category = '0' and subcatz = 'z3|';

Is het gewoon een kwestie van deze query uitvoeren elke keer nadat retrieve.php heeft gedraaid?

Jep in principe wel ja.

Ik ben nog opzoek naar een script voor het verkleinen van de commentsfull tabel :

https://github.com/spotweb/spotweb/issues/1418

Iemand met SQL kennis hiero ?

quote:

Koffie schreef op woensdag 22 februari 2012 @ 09:03:
Ik haal nu elke 10 minuten de updates binnen dmv een cron schedule van retrieve.php
Ik las op de mini wiki dat je bepaalde zooi uit de DB kunt verwijderen: https://github.com/spotweb/spotweb/wiki/Handige-query%27s
Het gaat mij specifiek om de porno die ik niet hoef.

Met deze query zou dat moeten lukken:

DELETE FROM spots, spotsfull, commentsxover, reportsxover, spotstatelist, reportsposted, cache USING spots
LEFT JOIN spotsfull ON spots.messageid=spotsfull.messageid
LEFT JOIN commentsxover ON spots.messageid=commentsxover.nntpref
LEFT JOIN reportsxover ON spots.messageid=reportsxover.nntpref
LEFT JOIN spotstatelist ON spots.messageid=spotstatelist.messageid
LEFT JOIN reportsposted ON spots.messageid=reportsposted.inreplyto
LEFT JOIN cache ON spots.messageid=cache.messageid
WHERE category = '0' and subcatz = 'z3|';

Is het gewoon een kwestie van deze query uitvoeren elke keer nadat retrieve.php heeft gedraaid?

Helaas, de cleanup query werkt niet:

#1054 - Unknown column 'cache.messageid' in 'on clause'

Iemand al eens met deze query gespeeld?

quote:

Koffie schreef op woensdag 22 februari 2012 @ 10:34:
[...]

Helaas, de cleanup query werkt niet:

#1054 - Unknown column 'cache.messageid' in 'on clause'

Iemand al eens met deze query gespeeld?

deze regel verwijderen
SQL:

1	LEFT JOIN cache ON spots.messageid=cache.messageid

quote:

Rmg schreef op woensdag 22 februari 2012 @ 10:51:
[...]


deze regel verwijderen
SQL:

1	LEFT JOIN cache ON spots.messageid=cache.messageid

Dan krijg ik weer "#1109 - Unknown table 'cache' in MULTI DELETE", terwijl de tabel cache wel degelijk bestaat

quote:

Koffie schreef op woensdag 22 februari 2012 @ 10:57:
[...]

Dan krijg ik weer "#1109 - Unknown table 'cache' in MULTI DELETE", terwijl de tabel cache wel degelijk bestaat

en eerste regel nog ff cache eruit halen. en ik run erna nog:

"OPTIMIZE TABLE spots , commentsxover" spotweb

slommer wijzigde dit bericht 22-02-2012 11:52 (11%)

Het werkt
die query is alleen wel een giga aanslag op je systeem zeg, zelfs als er maar een stuk of 10 nieuwe erotiek spots zijn moet hij er een paar minuutjes over nadenken

Hallo allemaal,

in deze (oude) post Warbringer in "SpotWeb - Webbased Spotnet" staat een stukje over crontabs. Daar staat een code voor een crontab regel die 1x per dag draait om 01:00 uur. Kun je die code ook aanpassen dat hij bijvoorbeeld om 4:00 uur begint te draaien?

Ik zit namelijk nog wel eens tot 2:00 - 2:30 uur online te gamen en ik merk dat mijn verbinding rond 1:00 uur minder wordt.

Alvast bedankt.

Bekijk dit eens.

quote:

psvjw schreef op woensdag 22 februari 2012 @ 13:07:
Hallo allemaal,

in deze (oude) post Warbringer in "SpotWeb - Webbased Spotnet" staat een stukje over crontabs. Daar staat een code voor een crontab regel die 1x per dag draait om 01:00 uur. Kun je die code ook aanpassen dat hij bijvoorbeeld om 4:00 uur begint te draaien?

Ik zit namelijk nog wel eens tot 2:00 - 2:30 uur online te gamen en ik merk dat mijn verbinding rond 1:00 uur minder wordt.

Alvast bedankt.

Dan pas je de regel toch aan naar 4 uur
code:

0 4 * * * cd /share/MD0_DATA/Web/spotweb/ ; /mnt/ext/opt/apache/bin/php -c /etc/config/ retrieve.php 1>/dev/null 2>/dev/null

quote:

slommer schreef op woensdag 22 februari 2012 @ 11:02:
[...]

en eerste regel nog ff cache eruit halen. en ik run erna nog:

"OPTIMIZE TABLE spots , commentsxover" spotweb

Ik heb nu de historie aan porn eruit gehaald, en draai nu elk half uur die opschoon query om nieuwe inserts weer te verwijderen.
Is die optimize structureel nodig na elke opschoonactie, of alleen na het verwijderen van die ellenlange historie

quote:

Koffie schreef op donderdag 23 februari 2012 @ 08:15:
[...]

Ik heb nu de historie aan porn eruit gehaald, en draai nu elk half uur die opschoon query om nieuwe inserts weer te verwijderen.
Is die optimize structureel nodig na elke opschoonactie, of alleen na het verwijderen van die ellenlange historie

Ik doe het 1x per week ongeveer omdat spotweb zelf dan ook even niet bereikbaar is.
server kan het op zich wel makkelijk aan gelukkig

quote:

slommer schreef op donderdag 23 februari 2012 @ 09:39:
[...]

Ik doe het 1x per week ongeveer omdat spotweb zelf dan ook even niet bereikbaar is.

duidelijk, dank je

quote:

server kan het op zich wel makkelijk aan gelukkig

Hmm, mijn Ubuntu gebakkie heeft 't er zwaar mee (maar draai de optimize voor het eerst sinds die mega-delete van gisteren).

quote:

Koffie schreef op donderdag 23 februari 2012 @ 09:41:
[...]

duidelijk, dank je

[...]

Hmm, mijn Ubuntu gebakkie heeft 't er zwaar mee (maar draai de optimize voor het eerst sinds die mega-delete van gisteren).

Tis een quadcore 3ghz bakkie. en mysql gebruikt maar 1core dus 3 over voor andere taken

Ik kan de update-knop nergens vinden, ben ingelogd als admin en in de groepsvoorkeuren staat deze gewoon aan zoals standaard. (Nieuwe spots ophalen knop tonen)

Iemand een idee? Is er ergens een setting die ik mis?

Llewy wijzigde dit bericht 23-02-2012 21:01 (8%)

Links onderin op de grijze knop 'retrieve' klikken.

---

Wat is de reden dat sommige spots geen NZB mogelijkheden hebben, zijn deze te oud (dat lijkt tot nu toe de overeenkomst tussen dergelijke spots te zijn nl.)?

quote:

Koffie schreef op donderdag 23 februari 2012 @ 21:07:

---

Wat is de reden dat sommige spots geen NZB mogelijkheden hebben, zijn deze te oud (dat lijkt tot nu toe de overeenkomst tussen dergelijke spots te zijn nl.)?

Ja die zijn volgens mij oud en hebben nog geen standaard een NZB file. Volgens mij zijn dit spots die uit FTD komen. Drazix heeft die toen geport en naar Spotnet geplaatst zodat er al een redelijke database aanwezig was. Op FTD waren geen NZB bestanden meer te vinden, alleen de filename. Dat is denk ik de reden.

quote:

Koffie schreef op donderdag 23 februari 2012 @ 21:07:
Links onderin op de grijze knop 'retrieve' klikken.

Ik zie dat knopje niet staan, bij mij staat daar Onderhoud, gevolgd door door de twee knoppen:
-Verwijder download geschiedenis
-Markeer alles als gelezen

Google geeft dat hij daartussen moet staan?

Je hebt wel al in de settings aangegeven wat je in je DB wilt, en daarna een handmatigeretrieve.php vamaf het console gedraait ?

quote:

slommer schreef op donderdag 23 februari 2012 @ 09:39:
[...]

Ik doe het 1x per week ongeveer omdat spotweb zelf dan ook even niet bereikbaar is.
server kan het op zich wel makkelijk aan gelukkig

Ik draait een linux servertje op VMWare server 2. Heb gisteren een 2e CPU toegeveogd aan de VM en geheugen van 1 naar 2 Gb gezet.
Als ik nu weer die optimize draai, duurt het dan weer zo lang of is het sowieso nog maar een fractie van de tijd omdat de boel al geoptimaliseerd is?
Gisteren heeft die optimize er ongeveer 6 uur over gedaan!

quote:

Koffie schreef op vrijdag 24 februari 2012 @ 07:33:
Je hebt wel al in de settings aangegeven wat je in je DB wilt, en daarna een handmatigeretrieve.php vamaf het console gedraait ?

Ik heb inderdaad al een gevulde database, als ik in de Terminal handmatig de Retrieve.php uitvoer (Mac). Het knopje updaten komt gewoon echt niet tevoorschijn..

probeer voor de gein eens een andere browser?

Sinds ik 'retrieve comments' uit heb gezet ziet spotweb er zo uit:


Het weer aanzetten helpt niet
Weet iemand een fix?

Edit: De layout ziet er weer normaal uit als ik de bestandsgrootte verberg..
Maar dat zie ik liever wel

Pistolebob wijzigde dit bericht 24-02-2012 17:36 (24%)

quote:

Koffie schreef op vrijdag 24 februari 2012 @ 13:15:
probeer voor de gein eens een andere browser?

Geprobeerd, maar biedt ook geen oplossing.. Ik snap er niets meer van..

Zie ook nergens een Error verschijnen.

Het admin account heeft geen "ophalen" knop.
Maak hiervoor een andere gebruiker aan of werk SpotWeb bij via retrieve.php.

Ik heb voor het eerst sinds een week of twee spotweb weer eens bijgewerkt. Nu zie ik naast de titel van de spot her-en-der een groene W opduiken. Iemand een idee wat dat is?

Volgens mij betekend dat WhiteListed

quote:

Nightspirit schreef op woensdag 22 februari 2012 @ 13:31:
Bekijk dit eens.

Tnx... Ook @mike_oo

quote:

qwerty_running schreef op zaterdag 25 februari 2012 @ 01:21:
Het admin account heeft geen "ophalen" knop.
Maak hiervoor een andere gebruiker aan of werk SpotWeb bij via retrieve.php.

Thanks, werkt inmiddels!

Volgende vraag: ik gebruik de mobile template om vanaf mijn iPhone te kunnen downloaden als ik de deur uit ben. Inmiddels logt hij standaard in via een admin account, maar echt veilig is dit natuurlijk niet.

Is er een mogelijkheid om om een login te vragen bij de mobiele versie?

quote:

Llewy schreef op dinsdag 28 februari 2012 @ 00:08:
[...]


Thanks, werkt inmiddels!

Volgende vraag: ik gebruik de mobile template om vanaf mijn iPhone te kunnen downloaden als ik de deur uit ben. Inmiddels logt hij standaard in via een admin account, maar echt veilig is dit natuurlijk niet.

Is er een mogelijkheid om om een login te vragen bij de mobiele versie?

Aangezien de mobile versie geen inlog-scherm heeft gaat dit normaal niet echt goed lukken. Wat je kan doen is het volgende: Je zou iets met .htaccess kunnen doen en een aparte mobile map met wat aparte regels in je ownsettings.php die kijkt of je mobile gebruikt of gewoon bent ingelogd..?

Dus gewoon nog een keer git clone spotweb zodat je twee spotweb mappen hebt
PHP:

1 2 3 4 5 6 7 8

<?php //gewone settings hiero if ((@strstr($_SERVER['REQUEST_URI'],"mobile")) ||  (@strstr($_SERVER['PWD'],"mobile"))) { //automatisch inloggen als admin.. $settings['nonauthenticated_userid'] = 1; } ?>

En dan nog een .htaccess in je mobile map zetten waardoor je in moet loggen. Moet je ze wel allebei git pullen bij een wijziging..
Op deze manier heb ik ook geen 'gewone' spotweb met commentsfull en spotsfull etc en nog een lightspots zonder comments en alleen 'spots'.

Xaero wijzigde dit bericht 28-02-2012 08:54 (36%)

quote:

Xaero schreef op dinsdag 28 februari 2012 @ 08:42:
[...]


Aangezien de mobile versie geen inlog-scherm heeft gaat dit normaal niet echt goed lukken. Wat je kan doen is het volgende: Je zou iets met .htaccess kunnen doen en een aparte mobile map met wat aparte regels in je ownsettings.php die kijkt of je mobile gebruikt of gewoon bent ingelogd..?

Dus gewoon nog een keer git clone spotweb zodat je twee spotweb mappen hebt
PHP:

1 2 3 4 5 6 7 8

<?php //gewone settings hiero if ((@strstr($_SERVER['REQUEST_URI'],"mobile")) ||  (@strstr($_SERVER['PWD'],"mobile"))) { //automatisch inloggen als admin.. $settings['nonauthenticated_userid'] = 1; } ?>

En dan nog een .htaccess in je mobile map zetten waardoor je in moet loggen. Moet je ze wel allebei git pullen bij een wijziging..
Op deze manier heb ik ook geen 'gewone' spotweb met commentsfull en spotsfull etc en nog een lightspots zonder comments en alleen 'spots'.

Dank voor je uitgebreide reactie, hier kan ik wat mee! Ik gebruikte de .htaccess manier al, maar dat werkte niet samen met couchpotato e.d.. Dubbele spotweb is inderdaad de eenvoudigste oplossing.

Heb ik alleen 1 vraag, kan ik mijn spotweb map ook kopieren? Als ik nog een git clone doe, dan geeft hij een foutmelding i.v.m. het al bestaan van de map.