[Ervaringen] Newznab

[Protax]

Ik ben bezig om NN+ op Linux (Ubuntu Server 12.10) te installeren.
Nu heb ik aan de hand van deze handleiding de boel geinstalleerd.

http://mikepugh.blogspot....8805#c6533208591897681495

Prima handleiding voor zo'n iemand als mij zonder Linux kennis, echter was de handleiding een beetje out dated.
Ik moest namelijk MySQL 5.5 installeren, en daarnaast moest ik het root account activeren om er soepel doorheen te lopen.

Aangekomen bij het NN+ install gedeelte, krijg ik het volgende:

Not Found

The requested URL /install was not found on this server.

Apache/2.2.22 (Ubuntu) Server at 192.168.236.129 Port 80

Iemand enig idee wat ik dan moet checken? Of waar het mis gaat?
Wie kan deze Linux noob op weg helpen? ;-)

[Verwijderd]

dx5314 schreef op maandag 11 februari 2013 @ 21:49:
Aangekomen bij het NN+ install gedeelte, krijg ik het volgende:

Not Found

The requested URL /install was not found on this server.

Apache/2.2.22 (Ubuntu) Server at 192.168.236.129 Port 80

Iemand enig idee wat ik dan moet checken? Of waar het mis gaat?
Wie kan deze Linux noob op weg helpen? ;-)

Kijk even of je in de geode dir zit. Bij mij zat-ie nl in http://ip/www/install

[Protax]

Verwijderd schreef op maandag 11 februari 2013 @ 21:52:
[...]

Kijk even of je in de geode dir zit. Bij mij zat-ie nl in http://ip/www/install

Nee, helaas

EDIT: Werkend gekregen! Handmatig de SVN gedownload, en uitgepakt. Bleek dat er geen bestanden waren geinstalleerd in de WWW directory. Handmatig daarheen gekopieerd, en toen werkte het

[ Voor 30% gewijzigd door Protax op 11-02-2013 23:17 ]

[Red Boll]

De laatste dagen blijft "runme_with_scrape.bat" hangen op "Stage 7 : Deleting unused binaries and parts".

Het gaat echt om uren, heb hem nu al een paar keer handmatig gestopt en weer opgestart.
Waar kan ik vinden waar de actie op blijft hangen?

[Delsin]

Stage 7 is volgens mij alleen het deleten van records uit binaries en parts.
Heb je niet enorm veel records in deze tabellen zitten?

DELETE parts, binaries
FROM parts
LEFT JOIN binaries ON binaries.ID = parts.binaryID
WHERE binaries.procstat IN (4, 6)
OR binaries.dateadded < now() - INTERVAL <nnn> HOUR

Die query kan heel lang duren als je database te vol is geraakt (backfilling misschien?).
Tel het aantal records in binaries met procstat 4 en 6 eens.

<nnn> staat voor het aantal dagen * 24 wat je in je site als retention hebt opgegeven.

Je kunt altijd proberen je imports te stoppen en de delete acties rechtstreeks vanuit een mysql console uit te voeren. En dan wachten tot de query klaar is anders raak je nooit van die records af.

[kmf]

Die delete acties duurden mij altijd te lang. Ik heb speciaal een script hiervoor geschreven die constant in batches zit te verwijderen. Stage 7 heb ik dan ook uitgeschakeld.

Zoek even in deze topic naar m'n delete-script.

[Tsurany]

Is het mogelijk om te zorgen dat newznab_screen.sh altijd draait? Vind het vrij vervelend als het middenin de nacht uit valt en ik daar pas 6 uur later achter kom.

[kmf]

Tsurany schreef op dinsdag 12 februari 2013 @ 09:11:
Is het mogelijk om te zorgen dat newznab_screen.sh altijd draait? Vind het vrij vervelend als het middenin de nacht uit valt en ik daar pas 6 uur later achter kom.

Je kan een monit-script maken die die dingen monitored.

[Verwijderd]

Tsurany schreef op dinsdag 12 februari 2013 @ 09:11:
Is het mogelijk om te zorgen dat newznab_screen.sh altijd draait? Vind het vrij vervelend als het middenin de nacht uit valt en ik daar pas 6 uur later achter kom.

Al zo vaak voorbij gekomen, jonnyboys script gebruiken of de server gewoon gebruiken waar je al bij zit

[Protax]

Verwijderd schreef op dinsdag 12 februari 2013 @ 13:33:
[...]

Al zo vaak voorbij gekomen, jonnyboys script gebruiken of de server gewoon gebruiken waar je al bij zit

Zo simpel is dat allemaal niet te vinden voor mensen die er nog niet zolang mee bezig zijn ;-)
Ik zit zelf nu met dezelfde vraag maar dan voor Ubuntu Server, er zijn staan namelijk twee vergelijkbare scripts in die folder:

newznab_screen.sh
newznab_ubuntu.sh

Welke moet ik nu gebruiken voor Ubuntu Server?
Daarna moet je het volgende doen:

cp newznab_screen.sh newznab_local.sh
edit newznab_local.sh to specify paths to your installation
chmod +x newznab_local.sh
screen bash
./newznab_local.sh
ctrl-ad to detach screen

Zorgt dit ervoor dat het script opstart bij het opstarten van de server, en blijft het hierna draaien?
Overigens als ik het script handmatig run, krijg ik deze melding:

Processing alt.binaries.x264
Group alt.binaries.x264 has 51,390 new parts.
First: 1351 Last: 91475417 Local last: 91424027
Getting 20,001 parts (91424028 to 91444028) - 31,389 in queue
Error 440: Unexpected response: 'admin not allowed'

Is die Error 440 iets om me druk over te maken?

[Coenen]

Het eerste wat in me opkomt is dat deze foutmelding van je usenet provider is. Alsof je als user admin hebt opgeven. Als dat het geval is zou ik me er druk over maken.

[Protax]

Coenen schreef op dinsdag 12 februari 2013 @ 15:06:
Het eerste wat in me opkomt is dat deze foutmelding van je usenet provider is. Alsof je als user admin hebt opgeven. Als dat het geval is zou ik me er druk over maken.

Hij heeft ook een aantal uur niets meer binnengehaald.
Maar ik geef toch nergens met credentials van mijn usenet provider op in NN+?

[Delsin]

Die error 440 slaat toch op compressed headers (die dan niet ondersteund worden door je provider)?
Heb je de optie Compressed headers niet per ongeluk aangezet in je site edit scherm?

[Coenen]

@dx5314, als het goed is heb je je credentials tijdens de installatie opgegeven, of de eerste keer dat je naar de install folder ging. Any way, check deze file: config.php in de www folder.

[Protax]

Delsin schreef op dinsdag 12 februari 2013 @ 15:15:
Die error 440 slaat toch op compressed headers (die dan niet ondersteund worden door je provider)?
Heb je de optie Compressed headers niet per ongeluk aangezet in je site edit scherm?

Held! Mijn dank is groot
Heb vanmorgen settings die hier voorbij kwamen uit het verleden toegepast, misschien iets voorzichtiger mee zijn.
Nu nog even uitvogelen hoe dat script precies in elkaar steekt...

[ Voor 12% gewijzigd door Protax op 12-02-2013 15:21 ]

[Verwijderd]

dx5314 schreef op dinsdag 12 februari 2013 @ 14:11:
[...]


Zo simpel is dat allemaal niet te vinden voor mensen die er nog niet zolang mee bezig zijn ;-)
Ik zit zelf nu met dezelfde vraag maar dan voor Ubuntu Server, er zijn staan namelijk twee vergelijkbare scripts in die folder:

newznab_screen.sh
newznab_ubuntu.sh

Welke moet ik nu gebruiken voor Ubuntu Server?
Daarna moet je het volgende doen:

cp newznab_screen.sh newznab_local.sh
edit newznab_local.sh to specify paths to your installation
chmod +x newznab_local.sh
screen bash
./newznab_local.sh
ctrl-ad to detach screen

Zorgt dit ervoor dat het script opstart bij het opstarten van de server, en blijft het hierna draaien?
Overigens als ik het script handmatig run, krijg ik deze melding:

Processing alt.binaries.x264
Group alt.binaries.x264 has 51,390 new parts.
First: 1351 Last: 91475417 Local last: 91424027
Getting 20,001 parts (91424028 to 91444028) - 31,389 in queue
Error 440: Unexpected response: 'admin not allowed'

Is die Error 440 iets om me druk over te maken?

Gebruik zelf Ubuntu server 12.10. Run de newznab_local.sh met behulp van de screen commando.

[Red Boll]

Delsin schreef op dinsdag 12 februari 2013 @ 07:34:
Heb je niet enorm veel records in deze tabellen zitten?

in binaries heb ik : 156,818 records
in parts : 40,756,326 records (best wel veel)

Delsin schreef op dinsdag 12 februari 2013 @ 07:34:
DELETE parts, binaries
FROM parts
LEFT JOIN binaries ON binaries.ID = parts.binaryID
WHERE binaries.procstat IN (4, 6)
OR binaries.dateadded < now() - INTERVAL <nnn> HOUR

De langste retentie is 365 dagen maar dat hebben ze (nog) niet allemaal.
Wanneer de query uitvoer met 365*24 worden er geen records verwijderd.

Delsin schreef op dinsdag 12 februari 2013 @ 07:34:
Die query kan heel lang duren als je database te vol is geraakt (backfilling misschien?).
Tel het aantal records in binaries met procstat 4 en 6 eens.

Ben inderdaad aan het backfillen geweest.

procstat 4 : 244
procstat 6 : 1

kmf schreef op dinsdag 12 februari 2013 @ 09:11:
Die delete acties duurden mij altijd te lang. Ik heb speciaal een script hiervoor geschreven die constant in batches zit te verwijderen. Stage 7 heb ik dan ook uitgeschakeld.

Zoek even in deze topic naar m'n delete-script.

Dank allebei! Zal mijn backfill acties met in ieder geval met kleinere stappen uitvoeren zodat de database niet meer zoveel van die klappen krijgt.

[ Voor 18% gewijzigd door Red Boll op 12-02-2013 22:06 ]

[Delsin]

Die retentie van 365 dagen is waarschijnlijk voor je groepen, dat is prima.

De retentie die je bij site kunt instellen voor raw headers is bepalend hoe lang records in parts en binaries bewaard moeten blijven. Standaard staat meen ik die op 1.5 dag.

Volgens mij kun je -als je aan het backfillen gaat- die retentie tijdelijk veel korter (of zelfs op 0) zetten.

Je kunt ook nog eens controleren of er veel orphaned records in parts zitten die in stage 7 niet worden opgeruimd. Ik heb gemerkt dat er best veel records achter kunnen blijven, kan in de miljoenen lopen.

select count(*) from parts p LEFT JOIN binaries b on binaryID = b.ID WHERE b.ID is null

Als dat een flink aantal geeft kun je die eerst proberen te verwijderen:

delete from parts where binaryID NOT IN (select ID from binaries)

Als je dan retentie kort zet en het releases script een tijd zijn werk laat doen zou je database vanzelf langzaam weer kleiner moeten worden.

[Red Boll]

Delsin schreef op dinsdag 12 februari 2013 @ 22:44:
De retentie die je bij site kunt instellen voor raw headers is bepalend hoe lang records in parts en binaries bewaard moeten blijven. Standaard staat meen ik die op 1.5 dag.

Inderdaad, zat 2 dingen door elkaar te halen. 365 is inderdaad voor sommige nieuwsgroepen.
Header Retention is 1.5, Release Retention is 0.

Delsin schreef op dinsdag 12 februari 2013 @ 22:44:
Je kunt ook nog eens controleren of er veel orphaned records in parts zitten die in stage 7 niet worden opgeruimd. Ik heb gemerkt dat er best veel records achter kunnen blijven, kan in de miljoenen lopen.

Wow, resultaat is 20128198, daar valt inderdaad nog wel iets te winnen.
Zodra het release script gelopen heeft zal ik de "opruim query" draaien.

[Thc_Nbl]

Ultimation schreef op dinsdag 11 december 2012 @ 12:40:
Gaat eerder om dat de database ook +25Gb kan worden. Dan begint MySQL toch wel een beetje te haperen.

Mysql haperen met 25+ GB, dan doe je echt wat fout hoor.
Mijn mysql DB is 106GB groot momenteel, en dat nog op een 32bit versie. ( 10Gb Ram, server met PAE )
De nieuwe server staat klaar, 64GB Ram. en 64bit

Beter kijken wat je kan optimaliseren in mysql zou ik zeggen, en ondanks de groote erg stabiel.
Mijn server heb ik helaas gisteren moeten herstarten na 1015 dagen up.

[Protax]

Goedenavond,

Valt hier nog iets aan te doen:



Ik kan niet veel met dat soort posts, maar volgens mij zijn het soms wel goede dingen die ze hernoemd hebben.
Zou leuk zijn om er wat meer info uit te krijgen, en als dit niet kan ze te hiden.

[ Voor 14% gewijzigd door Protax op 13-02-2013 20:20 ]

[Buzzie]

dx5314 schreef op woensdag 13 februari 2013 @ 20:20:
Goedenavond,

Valt hier nog iets aan te doen:

[afbeelding]

Ik kan niet veel met dat soort posts, maar volgens mij zijn het soms wel goede dingen die ze hernoemd hebben.
Zou leuk zijn om er wat meer info uit te krijgen, en als dit niet kan ze te hiden.

'
Zorgen dat je update_parsing.php gebruikt die in testing staat.
Zorg er wel voor dat echo = false staat....goed lezen wat voor uitleg er in dat script staat

[Verwijderd]

Buzzie schreef op woensdag 13 februari 2013 @ 20:21:
[...]

'
Zorgen dat je update_parsing.php gebruikt die in testing staat.
Zorg er wel voor dat echo = false staat....goed lezen wat voor uitleg er in dat script staat

En vooral het laatste is belangrijk dan heb ik met mij vele effe tien keer moeten lezen true en false pfff

[Delsin]

Je kunt ook nog met je regexes gaan spelen. De releases zijn hier namelijk op basis van de prefix van de post samengesteld, maar in de post fiels zie je ook duidelijk wat het is:

f86bfec54d98df07a4125ed26c5c27cc [03/18] - "00-little_indian_rabbits-4th_round-2011-eithel.nfo" yEnc

Een regex die eerst de naam pakt tussen de \" \" een lagere ordinal geven dan één die de name pakt uit de prefix zou kunnen helpen. Maar daarvoor moet je wel goed kijken of je daarmee niet andere releases in die zelfde groep verziekt.

Voor deze post zou update parsing in theorie kunnen helpen omdat er netjes een nfo bij zit...

[bmaster001]

Is er een mogelijkheid om de blacklist toe te passen met terugwerkende kracht? Ik ben al een paar dagen aan 't indexeren met min-of-meer standaard instellingen, en dus zonder blacklist. Maar nu zit ik met een hoop german-releases en dergelijke. Nu heb ik wel de blacklists van nivong toegevoegd, en het zou leuk zijn moest ik deze ook kunnen toepassen op de bestaande database...

[Xenophoben]

Buzzie schreef op woensdag 13 februari 2013 @ 20:21:
[...]

'
Zorgen dat je update_parsing.php gebruikt die in testing staat.
Zorg er wel voor dat echo = false staat....goed lezen wat voor uitleg er in dat script staat

In welke line staat dat

[Coenen]

Ergens in het begin. Je ziet het vanzelf.

[kmf]

Thc_Nbl schreef op woensdag 13 februari 2013 @ 10:58:
[...]


Mysql haperen met 25+ GB, dan doe je echt wat fout hoor.
Mijn mysql DB is 106GB groot momenteel, en dat nog op een 32bit versie. ( 10Gb Ram, server met PAE )
De nieuwe server staat klaar, 64GB Ram. en 64bit

Beter kijken wat je kan optimaliseren in mysql zou ik zeggen, en ondanks de groote erg stabiel.
Mijn server heb ik helaas gisteren moeten herstarten na 1015 dagen up.

Als jouw mysql DB voor newznab meer dan 100GB is, dan doe je toch wel wat fout...

[zeroday]

kmf schreef op donderdag 14 februari 2013 @ 09:42:
[...]


Als jouw mysql DB voor newznab meer dan 100GB is, dan doe je toch wel wat fout...

4 a 5 groepjes en ik heb 1GB ..

[kmf]

zeroday schreef op donderdag 14 februari 2013 @ 14:30:
[...]


4 a 5 groepjes en ik heb 1GB ..

Ik heb 36 groepen die ik indexeer + een archief van 30weken geleden tot 5+ jaar terug van alle groepen.
De geindexeerde groepen zijn ook nog eens backfilled tot 300 dagen.
17.500 pagina's aan releases.

Ik heb een header-retentie van 2 dagen zodat nieuwe uploads 2 dagen de tijd hebben om volledig te worden.

De ruwe databasefiles samen is 2.1GB op dit moment.

Als je database te groot is dan heb je te maken met een combinatie van de volgende zaken.
1) overvolle parts+binaries-tabellen die je niet opgeschoond hebt.
2) een innodb database welke maar 1 datafile heeft ipv een datafile per tabel
3) nooit de optimize-commando uitgevoerd
4) hele slechte regex zodat je een enorme hoop unprocessed headers hebt.


*Alle releases worden uiteindelijk nzb-bestanden op je HDD. De database onthoudt alleen de metadata. Als een release eenmaal gemaakt is, heb je de parts/binaries niet meer nodig.

[henwy]

kmf schreef op donderdag 14 februari 2013 @ 14:44:
[...]
2) een innodb database welke maar 1 datafile heeft ipv een datafile per tabel

Ik ben dus zo iemand die wel innodb draait maar met 1 datafile. Is dat nog makkelijk te splitsen?

[kmf]

henwy schreef op donderdag 14 februari 2013 @ 15:37:
[...]


Ik ben dus zo iemand die wel innodb draait maar met 1 datafile. Is dat nog makkelijk te splitsen?

Ja.
Wat je moet doen is een mysqldump maken van je database nu (wel effe alle indexprocessen stoppen)
settings wijzigen naar per table (zoek effe naar m'n posts hier in dit topic)
restart mysql
en restore je backup.

[henwy]

kmf schreef op donderdag 14 februari 2013 @ 15:49:
[...]


Ja.
Wat je moet doen is een mysqldump maken van je database nu (wel effe alle indexprocessen stoppen)
settings wijzigen naar per table (zoek effe naar m'n posts hier in dit topic)
restart mysql
en restore je backup.

Wel even een truncate van alles voor de herstart denk ik?

[Protax]

Ik heb nu echt een probleem veroorzaakt.

Van de week dit aangepast in rc.local:

/var/www/newznab/misc/sphinx/nnindexer.php daemon
screen -S newznab sh /var/www/newznab/misc/update_scripts/nix_scripts/newznab_screen_local.sh

Dit zodat het script automatisch opstart.

Nu heb ik op advies van het medetweaker het script als volgt aangepast:

#!/bin/sh
# call this script from within screen to get binaries, processes releases and
# every half day get tv/theatre info and optimise the database

set -e

export NEWZNAB_PATH="/var/www/newznab/misc/update_scripts"
export NEWZNAB_SLEEP_TIME="300" # in seconds
LASTOPTIMIZE=`date +%s`

while :

do
CURRTIME=`date +%s`
cd ${NEWZNAB_PATH}
php ${NEWZNAB_PATH}/update_binaries_threaded.php
php ${NEWZNAB_PATH}/update_releases.php
php /var/www/newznab/misc/testing/update_cleanup.php
php /var/www/newznab/misc/testing/update_parsing.php
# php /var/www/newznab/www/admin/nzb-importmodified.php /var/www/newznab/tempnzbs/imp$
php ${NEWZNAB_PATH}/update_releases.php

DIFF=$(($CURRTIME-$LASTOPTIMIZE))
if [ "$DIFF" -gt 43200 ] || [ "$DIFF" -lt 1 ]
then
LASTOPTIMIZE=`date +%s`
/usr/bin/php5 ${NEWZNAB_PATH}/optimise_db.php
/usr/bin/php5 ${NEWZNAB_PATH}/update_tvschedule.php
/usr/bin/php5 ${NEWZNAB_PATH}/update_theaters.php
fi

echo "waiting ${NEWZNAB_SLEEP_TIME} seconds..."
sleep ${NEWZNAB_SLEEP_TIME}

done

Opgeslagen en vervolgens herstart.
Sinds de herstart wordt NN+ niet meer bijgewerkt en daarnaast kan ik ook niet meer het commando geven sudo screen -r -d waarmee ik normaal het proces van het script kon bekijken.
Krijg dit soort meldingen;

root@ubuntu:~# sudo screen -r -d
There is no screen to be detached.

Zou iemand weten wat ik kan doen om de boel weer aan de gang te krijgen? Ik zelf zie namelijk niets fout staan (al is mijn Linux kennis geen tot minimaal).

Alvast bedankt voor de hulp

EDIT:
Krijg bij één van de stappen deze melding:
PHP Fatal error: Call to undefined method DB::getAssocArray() in /var/www/newznab/misc/testing/update_cleanup.php on line 73
root@ubuntu:/var/www/newznab/misc/update_scripts/nix_scripts# Call to undefined method DB::getAssocArray() in /var/www/newznab/misc/testing/update_cleanup.php on line 73

en

PHP Fatal error: Undefined class constant 'CAT_MISC_OTHER' in /var/www/newznab/misc/testing/update_parsing.php on line 54
root@ubuntu:/var/www/newznab/misc/update_scripts/nix_scripts#

[ Voor 12% gewijzigd door Protax op 14-02-2013 17:41 ]

[kmf]

henwy schreef op donderdag 14 februari 2013 @ 15:54:
[...]

Wel even een truncate van alles voor de herstart denk ik?

Waarom? Wil je alles kwijtraken?

[henwy]

kmf schreef op donderdag 14 februari 2013 @ 16:31:
[...]

Waarom? Wil je alles kwijtraken?

1. mysqldump
2. innopertable
3. restart mysqld
4. import dump

Moet hier nog iets tussen? dat je tables leeg zijn oid? Dat bedoelde ik.

[kmf]

henwy schreef op donderdag 14 februari 2013 @ 16:34:
[...]


1. mysqldump
2. innopertable
3. restart mysqld
4. import dump

Moet hier nog iets tussen? dat je tables leeg zijn oid? Dat bedoelde ik.

Nee, want als je gaat importeren worden de tabellen vanzelf leeggegooid. Vergeet niet eerst de scripts te stoppen alvorens je gaat dumpen.

[Protax]

Zou iemand me nog kunnen helpen met de vraag een paar posts hierboven?
Ik zie door de bomen het bos niet meer

[CyberJack]

dx5314 schreef op vrijdag 15 februari 2013 @ 11:37:
Zou iemand me nog kunnen helpen met de vraag een paar posts hierboven?
Ik zie door de bomen het bos niet meer

Het eerste wat mij te binnen schiet is dat je omgeving niet helemaal up-to-date is.
Het lijkt er namelijk op dat scripts gebruik maken van oude code, en dat kan veroorzaakt zijn door een svn update niet op de gehele omgeving, maar op een subdirectory.
Een svn update vanuit een subdirectory zorgt ervoor dat alleen die (en alle onderliggende directories) geupdate worden, waardoor je dat in andere directories met oude code blijft zitten.

Dus in het kort, probeer eerst je gehele omgeving eens bij te werken.

[Red Boll]

Newznab draait nog steeds goed en ik heb geen last meer van vertragingen bij "stage 7".

Zit nog wel met een andere ding(etje). Sphinx lijkt nog niet goed te werken.

Na bepaalde zoekacties staat boven aan de pagina (gebeurd niet bij iedere zoekactie):
Warning: mysqli_connect(): (HY000/2002): No connection could be made because the target machine actively refused it. in W:\xampp\htdocs\nn\www\lib\sphinx.php on line 639

Ondanks de melding verschijnen er wel zoekresultaten.

CouchPotato kan krijgt geen data van Newsnab en in de log van CouchPotato verschijnt:
17:15:58 ERROR [ app.lib.provider.rss] Error parsing RSS. junk after document element: line 2, column 0

Wanneer ik de RSS feed bekijk staat er:
<b>Warning</b>: mysqli_connect(): (HY000/2002): No connection could be made because the target machine actively refused it.

Op regel 639 van sphinx.php staat standaard:
$sdb = mysqli_connect($hostport[0], "root", "", "", $hostport[1]);

Het lijkt dat er een db user, password, name & server bekend gemaakt moet worden hier, heb al meerdere volgordes neergezet van de database info maar ik blijf de foutmeldingen houden.

Wat moet ik hier neerzetten?

[Verwijderd]

*knip*

[ Voor 120% gewijzigd door Verwijderd op 04-03-2013 19:21 ]

[RudolfR]

Mooi initiatief. Bedankt!

[Dacuuu]

Perfect zo

[ Voor 96% gewijzigd door Dacuuu op 04-03-2013 19:56 ]

[Freekers]

Verwijderd schreef op zondag 17 februari 2013 @ 20:54:
Gratis Newznab community:

- Geen API Key
- Geen frontend/website alleen een API
- Compatible met Sickbeard & Couchpotato

Interessant, vooral dat hele geen frontend verhaal. Als je niet weet waar je naar op zoek bent, weet je niet dat het er is zullen we maar zeggen. Beetje hetzelfde concept als 'lolo', de indexer van Sickbeard zelf. Ook geen frontend, maar werkt perfect samen met Sickbeard

Zit sterk te overwegen om mijn newznab installatie hier naar om te toveren. Stukje 'veiliger'

[Elect]

Verwijderd schreef op zondag 17 februari 2013 @ 20:54:
Gratis Newznab community:

<aangepast op verzoek>

De server maakt legaal gebruik van verschillende gesloten communities om zo jullie te voorzien van alle NZB files. Als een release niet gevonden kan worden, worden er raw searches gedaan hierdoor is er een minieme kans dat je een release niet kunt vinden.

Voorlopig publiek toegankelijk

Veel eigen code/aanpassingen moeten doen om dit zo op te zetten? Ik weet niet of het dan makkelijk is om met de updates mee te komen van Newznab zelf?

Mooi initiatief. Ik ga hem iig toevoegen

[ Voor 9% gewijzigd door Elect op 06-03-2013 08:18 ]

[Verwijderd]

*knip*

[ Voor 104% gewijzigd door Verwijderd op 04-03-2013 19:21 ]

[Protax]

edit

Voorlopig publiek toegankelijk
[/quote]

Thanks, ik ga hem ook toevoegen als backup

[ Voor 73% gewijzigd door Protax op 05-03-2013 20:50 ]

[Verwijderd]

Done op verzoek

SuperB :-)

[ Voor 90% gewijzigd door Verwijderd op 05-03-2013 01:23 ]

[Coenen]

Ik heb hem ook al toegevoegd. Je kan tegenwoording niet genoeg back ups hebben.

[Tsurany]

Ik moet de eerste release nog zien die niet door mijn eigen Newznab of de Sickbeard Index opgepikt wordt. Heb een stuk of 10 Newznab accounts maar die worden allemaal niet gebruikt om releases vandaan te plukken

Ga deze mooi toevoegen en dan tezamen met mijn eigen en de Sickbeard Index, dan heb ik genoeg

[Coenen]

Ondanks m'n eigen Newznab en de Sickbeard index heb ik de laatste aflevering Californication via de indexer van JaHetIsChris gedownload. Mijn Newznab heeft hem nog niet.

[Slurpgeit]

S06E06? Die staat er bij mij al 2 uur op . Via a.b.teevee.

[Coenen]

Bij mij ook al 2 uur, ik wist niet eens dat ie er was.

code:

Completed   2013-02-18 18:47:03
Name    download

Ik wou alleen aangeven dat ik dacht dat ik genoeg zoekmachines had. Die van Jahetischris is sneller dan mijn eigen zoekmachine/indexer/newznab.

De naam is alleen een beetje onhandig: download. Nu gooit Sabnzbd hem in de verkeerde directory...

/edit, hmm, het lijkt erop dat m'n newznab al een tijdje niks meer gedaan heeft.
Dat zou wel een hoop verklaren.

[ Voor 13% gewijzigd door Coenen op 18-02-2013 20:59 ]

[Verwijderd]

=*knip*

[ Voor 108% gewijzigd door Verwijderd op 04-03-2013 19:20 ]

[Coenen]

Dezelfde naam als de uiteindelijke .mkv filenaam (na het uitpakken van de rars).

Van SABnzdb:

code:

Completed   2013-02-12 05:18:59
Name    Filenaam_na_uitpakken.
Size    818 MB
Status  Completed
Category    tv
Path    E:\ServerFolders\blablabla
Download    Downloaded in 1 minute 22 seconds at an average of 10.0 MB/s
Source  http://localhost:
Unpack  [Filenaam_na_uitpakken.] Unpacked 1 files/folders in 5 seconds
Repair  [Filenaam_na_uitpakken.] Quick Check OK

Name en Unpack zijn normaal hetzelfde. Ik weet alleen niet waar SABnzbd "NAME" vandaan haalt.
(Lastig uitleggen, btw)

//Edit, nog een die niet 'goed' gaat: The Following:

code:

Name    Th

[ Voor 6% gewijzigd door Coenen op 19-02-2013 07:16 ]

[bmaster001]

Ik gebruikte de afgelopen dagen mijn blockaccount bij Astraweb voor m'n private newznab server, omdat ik die toch nog had liggen, maar die account is nu "leeg". Is een cheapnews flat-fee account een goed alternatief? Of zijn er andere usenet providers die aan te raden zijn voor het vullen van een newznab server?

[Elect]

Ik gebruik nog steeds naar alle tevredenheid i-telligent voor het vullen van mijn newznab. Ik heb Cheapnews en Tweak gebruikt, maar beide met mindere resultaten.

[bmaster001]

Bedankt voor de tip Elect, die ga ik zeker ook eens bekijken.

Bij astraweb had ik de header compression aanstaan, maar dat gaat dacht ik niet met de meeste andere providers. Enig idee hoeveel het verschil in bandbreedte verschilt tussen beide manieren?

[Delsin]

bmaster001 schreef op dinsdag 19 februari 2013 @ 08:04:
Is een cheapnews flat-fee account een goed alternatief? Of zijn er andere usenet providers die aan te raden zijn voor het vullen van een newznab server?

Ik gebruikte Sunny. Maar omdat ik regelmatig zeer veel repairparts had ben ik geswitched naar supernews met de aanbieding die op de chat vaak langs komt. Sindsdien inderdaad geen repair meer nodig gehad, dus werkt voor newznab prima wat mij betreft.

[Protax]

Heb sinds een aantal dagen NN+ draaien op een Windows VM, en tot nu toe draait dit prima (heb Linux opgegeven).
Het enige waar ik tegen aanloop is dat de NN+ site draait op http://192.168.0.99/newznab/www/, op zich geen probleem, maar het lijkt net of Sickbeard daar niet mee kan omgaan.
Is het mogelijk om dit achteraf aan te passen of iets dergelijks zodat NN+ gewoon bereikbaar is op het IP of /newznab?

Feb-20 06:27:15 ERROR SEARCHQUEUE-RSS-SEARCH :: Error loading Newznab URL: http://192.168.0.99/newzn...=tvsearch&cat=5040%2C5030

[ Voor 20% gewijzigd door Protax op 20-02-2013 10:44 ]

[Buzzie]

dx5314 schreef op woensdag 20 februari 2013 @ 09:48:
Heb sinds een aantal dagen NN+ draaien op een Windows VM, en tot nu toe draait dit prima (heb Linux opgegeven).
Het enige waar ik tegen aanloop is dat de NN+ site draait op http://192.168.0.99/newznab/www/, op zich geen probleem, maar het lijkt net of Sickbeard daar niet mee kan omgaan.
Is het mogelijk om dit achteraf aan te passen of iets dergelijks zodat NN+ gewoon bereikbaar is op het IP of /newznab?

Feb-20 06:27:15 ERROR SEARCHQUEUE-RSS-SEARCH :: Error loading Newznab URL: http://192.168.0.99/newzn...=tvsearch&cat=5040%2C5030

pssst.....haal even je api key uit je post

[Protax]

Buzzie schreef op woensdag 20 februari 2013 @ 10:13:
[...]


pssst.....haal even je api key uit je post

Done thanks

[Verwijderd]

Je moet je document_root (apache) of root (nginx) naar de www folder veranderen in de configuratiefile voor je (virtuele) website.

Misschien even een tutorial voor nn zoeken, iedere tut die ik ooit ben tegengekomen bespreekt dit

[Protax]

Verwijderd schreef op woensdag 20 februari 2013 @ 11:22:
Je moet je document_root (apache) of root (nginx) naar de www folder veranderen in de configuratiefile voor je (virtuele) website.

Misschien even een tutorial voor nn zoeken, iedere tut die ik ooit ben tegengekomen bespreekt dit

Gevonden, afwachten of het werkt

[Coenen]

Bij mij pikt Sickbeard als ik dit instel als Newznab provider prima: http://localhost:8085/www/

[wauwwie]

dx5314 schreef op woensdag 20 februari 2013 @ 09:48:
Heb sinds een aantal dagen NN+ draaien op een Windows VM, en tot nu toe draait dit prima (heb Linux opgegeven).
Het enige waar ik tegen aanloop is dat de NN+ site draait op http://192.168.0.99/newznab/www/, op zich geen probleem, maar het lijkt net of Sickbeard daar niet mee kan omgaan.
Is het mogelijk om dit achteraf aan te passen of iets dergelijks zodat NN+ gewoon bereikbaar is op het IP of /newznab?

Feb-20 06:27:15 ERROR SEARCHQUEUE-RSS-SEARCH :: Error loading Newznab URL: http://192.168.0.99/newzn...=tvsearch&cat=5040%2C5030

Dat komt omdat je de root van je website in IIS op de newznab folder gezet hebt. Als je dit aanpast naar de "www" folder, 'een laag dieper, dan werkt het zoals je verwacht.

Ik draai het zelf in een VM met Server 2012 op een Hyper-V 2012 host en wilde graag gebruik maken van de dynamic memory functionaliteit daarvan. Ik moet zeggen het valt mij niet tegen, ik had meer problemen verwacht om het werkend te krijgen. Loopt prima. Alleen jammer dat de PHP software op windows niet x64 is.

[Delsin]

wauwwie schreef op donderdag 21 februari 2013 @ 11:57:
[...]
Ik draai het zelf in een VM met Server 2012 op een Hyper-V 2012 host en wilde graag gebruik maken van de dynamic memory functionaliteit daarvan. Ik moet zeggen het valt mij niet tegen, ik had meer problemen verwacht om het werkend te krijgen. Loopt prima. Alleen jammer dat de PHP software op windows niet x64 is.

Heb ongeveer de zelfde setup. Ben absoluut geen problemen tegen gekomen, loopt uitstekend en snel.
Heb nu wel de database helemaal vervangen door postgresql. Is een stuk prettiger qua geheugen gebruik voor de server.

Maar nou je het zegt, de standaard php in de wpi is nog 32bit. Bij apache is echter al wel een 64bit versie voor Windows te vinden: Apache

Zelf nog niet geprobeerd, leuk klusje voor het weekend denk ik.


Edit: ondertussen 5.4.10 threadsafe x64 versie gedownload en in gebruik genomen.
De ini van 5.4 overgenomen, enkel wat paden aangepast. NN+ loopt er zo te zien prima op.
Laat hem nu maar eens een nachtje met 10 threads lopen, morgen zien of er nog vreemde
problemen opduiken.

[ Voor 15% gewijzigd door Delsin op 21-02-2013 20:52 ]

[Qli-max]

nevermind

[ Voor 94% gewijzigd door Qli-max op 22-02-2013 18:21 ]

[Kashika]

Bij sickbeard krijg ik de volgende error met opennzb: Error while searching OpenNZB, skipping: list index out of range

Enig idee wat er mis is? Ik heb de link zoals hierboven vermeld ingevuld als search provider.

[Verwijderd]

Kashika schreef op zaterdag 23 februari 2013 @ 10:22:
Bij sickbeard krijg ik de volgende error met opennzb: Error while searching OpenNZB, skipping: list index out of range

Enig idee wat er mis is? Ik heb de link zoals hierboven vermeld ingevuld als search provider.

*knip*

[ Voor 13% gewijzigd door Verwijderd op 04-03-2013 19:20 ]

[Verwijderd]

Voor de mensen die hun blacklists willen uitbreiden: http://blog.phile.biz/pos...19/useful-blacklist-rules

[Verwijderd]

Thanks Am1g0

[Kashika]

Verwijderd schreef op zaterdag 23 februari 2013 @ 12:39:
[...]

Heb je een tijdstip waarop dit gebeurde? Is waarscheinlijk gebeurt tijdens het debuggen van wat code

Gebeurde vrijdagavond t/m zaterdagochtend.

[Verwijderd]

Verwijderd schreef op zaterdag 23 februari 2013 @ 14:55:
Voor de mensen die hun blacklists willen uitbreiden: http://blog.phile.biz/pos...19/useful-blacklist-rules

Ppffff zo ouderwets hehe even naar mijn github gaan daar is een up to date versie.
Github.com/nivong

[Oxize]

api key van AniDB is gebanned?

[Verwijderd]

Oxize schreef op zondag 24 februari 2013 @ 11:40:
api key van AniDB is gebanned?

Gebruik me eigen keys zoals iedereen zou moeten doen. Dus geen idee.

[Dacuuu]

Oxize schreef op zondag 24 februari 2013 @ 11:40:
api key van AniDB is gebanned?

Je bedoeld dat ip adres die hier gegeven is een paar dagen geleden? die geeft hier ook errors aan..

[lexi1986]

Weet iemand hier wat een slimme manier is van het vullen van Newznab? Ik wil graag tot een jaar terug alles kunnen zoeken en zien. Als ik bij de groep de Backfill days op 365 zet en dan backfill.php run haalt die wat op maar niet veel.

Ik gebruik Newznab+

Edit: Zie nu ook errors naar voren komen: Could not select group (bad name?) krijg ik bij veel grote groepen. Iemand een idee?

[ Voor 20% gewijzigd door lexi1986 op 24-02-2013 14:12 ]

[Oxize]

Verwijderd schreef op zondag 24 februari 2013 @ 12:20:
[...]

Gebruik me eigen keys zoals iedereen zou moeten doen. Dus geen idee.

AniDB key kan je niet veranderen via de adminsite. Dat moet je ergens in het phpscript doen. Ik gebruik namelijk eigen amazon/tvrage keys. Van AniDB kon ik zo snel niet vinden.

[Red Boll]

lexi1986 schreef op zondag 24 februari 2013 @ 13:23:
Weet iemand hier wat een slimme manier is van het vullen van Newznab?

Afhankelijk van de groep/releases doe ik het bijvoorbeeld per groep en dan per week of twee weken tegelijk om het normale update script niet teveel in de weg te zitten.

Dus: retentie van een groep met een week of wat ophogen en dan het backfill script draaien waarna het update script weer aan de gang kan. Pas daarna hoog ik weer een groep op.

lexi1986 schreef op zondag 24 februari 2013 @ 13:23:
Edit: Zie nu ook errors naar voren komen: Could not select group (bad name?) krijg ik bij veel grote groepen. Iemand een idee?

Bad name error krijg ik ook af en toe, dan start ik het script gewoon weer opnieuw op en dan gaat het wel goed.

[lexi1986]

Red Boll schreef op zondag 24 februari 2013 @ 22:00:
[...]

Afhankelijk van de groep/releases doe ik het bijvoorbeeld per groep en dan per week of twee weken tegelijk om het normale update script niet teveel in de weg te zitten.

Dus: retentie van een groep met een week of wat ophogen en dan het backfill script draaien waarna het update script weer aan de gang kan. Pas daarna hoog ik weer een groep op.


[...]

Bad name error krijg ik ook af en toe, dan start ik het script gewoon weer opnieuw op en dan gaat het wel goed.

Thanks ik probeerde meteen een jaar, daarom krijg ik ook die errors van bad name. Als ik de groep handmatig update werkt het wel zie ik nu. Ik ga ze per 1 a 2 weken updaten en kijken of die alles pakt. Thanks voor je reactie.

[Tsurany]

De laatste tijd krijg ik opeens dat hij gaat repairen met 1-2 miljoen articles aan overhead. Iemand een idee waar dit vandaan komt? Vrij irritant want hij hangt hierdoor flink.

[whitecrow]

Tsurany schreef op maandag 25 februari 2013 @ 09:27:
De laatste tijd krijg ik opeens dat hij gaat repairen met 1-2 miljoen articles aan overhead. Iemand een idee waar dit vandaan komt? Vrij irritant want hij hangt hierdoor flink.

Heb ik ook gehad, voornamelijk bij a.b.boneless uiteindelijk was de oplossing het Empty maken van binaries, parts en repairparts in de MySQL database.
Hierna heb ik er geen last meer van gehad.

[Delsin]

Tsurany schreef op maandag 25 februari 2013 @ 09:27:
De laatste tijd krijg ik opeens dat hij gaat repairen met 1-2 miljoen articles aan overhead. Iemand een idee waar dit vandaan komt? Vrij irritant want hij hangt hierdoor flink.

Gebeurde bij mij ook. Ik denk dat er ergens flink wat articles gedelete zijn. Zelf heb ik alleen de partrepair table leeg gemaakt voor alle parts die al twee keer geprobeerd waren en daarna liep alles weer normaal verder.

[Tsurany]

Ja het loste het probleem wel op, maar blijft irritant dat het voor komt. Helaas niet veel aan te doen dus.

[whitecrow]

@nivong Is er al meer bekend over de volgende update ?
Ik ben benieuwd hoe de spotnab uitbreiding gaat werken.

[Verwijderd]

whitecrow schreef op maandag 25 februari 2013 @ 13:21:
@nivong Is er al meer bekend over de volgende update ?
Ik ben benieuwd hoe de spotnab uitbreiding gaat werken.

niet dat ik weet, BB is zelf weg geweest en ik ook vandaar dat het op een laag pitje staat, verwacht het wel de eerste week van mei, aangezien het testen al begonnen is.

[Coenen]

Pfff, m'n newznab doet het nog... Gister was de SSD in m'n server kapot gegaan. Doet helemaal niks meer.
Vanochtend andere schijf erin en de boel restoren. Het heeft even geduurt, maar ik heb weer een werkende server. Helaas nu zonder SSD, maar wel zo'n momentus hybride schijfje. Dus nog steeds wel iets SSD.

[kmf]

tip: check van tijd tot tijd de tmpunrar-directory. als die vol zooi zit dan kan postprocessing mis gaan lopen.

Coenen schreef op vrijdag 01 maart 2013 @ 15:31:
Pfff, m'n newznab doet het nog... Gister was de SSD in m'n server kapot gegaan. Doet helemaal niks meer.
Vanochtend andere schijf erin en de boel restoren. Het heeft even geduurt, maar ik heb weer een werkende server. Helaas nu zonder SSD, maar wel zo'n momentus hybride schijfje. Dus nog steeds wel iets SSD.

Hmm... thanks for the reminder. Ik was vergeten dat ik nog een backup moet gaan inregelen.

[Verwijderd]

Jeetje dat is zwaar klote zeg, balen. Gelukkig dat je weer loopt! Ik loop nu al bijna 14 dagen non stop en gaat lekker, sinds kort ook spotweb erbij en dit helpt heeeeel veel zeg !

https://github.com/nivong/Update-scripts
Nieuwe branche trouwens, voor de interesseerde

[Coenen]

Het grootste geklooi was om de installatie CD via m'n laptop gemount te krijgen aan/op m'n server, dit werkte niet meer. Tot dat ik de power even van m'n server even los had gehaald. Gek kVM gebeuren met Java.
Helaas ben ik wel wat kwijt geraakt van m'n D schijf, deze werd niet helemaal geback upped.

[Verwijderd]

Dat is balen..... hopelijk gaat het weer goed Coenen... Nivong thanks again voor de update scripts. :-)

[Verwijderd]

Ergens had ik het advies gelezen om de parts, binaries en partrepair tabellen op innodb ipv myisam te zetten.
Na het indexen van een aantal nieuwsgroepen had ik een db van 17 GB en 45 GB aan schijfruimte die werd gebruikt. Het probleem zat hem in de ibdata1 file die dus enorm groot was.

Uiteindelijk besloten om een backup te maken en de tabellen om te zetten naar myisam via:

code:

sudo mysql -p
use newznab;
ALTER TABLE parts ENGINE = myisam;
ALTER TABLE binaries ENGINE = myisam;
ALTER TABLE partrepair ENGINE = myisam;
quit

Vervolgens de innodb files weggegooid, de database geoptimezed met true en de server herstart.

db grootte: 256 MB
Ingenomen schijfruimte: 8 GB

[kmf]

Verwijderd schreef op vrijdag 01 maart 2013 @ 22:10:
Ergens had ik het advies gelezen om de parts, binaries en partrepair tabellen op innodb ipv myisam te zetten.
Na het indexen van een aantal nieuwsgroepen had ik een db van 17 GB en 45 GB aan schijfruimte die werd gebruikt. Het probleem zat hem in de ibdata1 file die dus enorm groot was.

Uiteindelijk besloten om een backup te maken en de tabellen om te zetten naar myisam via:

code:

sudo mysql -p
use newznab;
ALTER TABLE parts ENGINE = myisam;
ALTER TABLE binaries ENGINE = myisam;
ALTER TABLE partrepair ENGINE = myisam;
quit

Vervolgens de innodb files weggegooid, de database geoptimezed met true en de server herstart.

db grootte: 256 MB
Ingenomen schijfruimte: 8 GB

je hebt de advies niet helemaal uitgelezen denk ik. Voordat je innodb gebruikt moet je wel eerst datafile per table doen.

[Verwijderd]

kmf schreef op vrijdag 01 maart 2013 @ 22:11:
[...]


je hebt de advies niet helemaal uitgelezen denk ik. Voordat je innodb gebruikt moet je wel eerst datafile per table doen.

Ja, het is ergens mis gegaan

[Henkske]

Luitjes, heeft er iemand hier misschien een goeie parsing script ? vooral in de groep *.etc heb ik veel getallen als releasenames terwijl er in de rar de juiste filenames staan. Dit moet toch op te lossen zijn?

[Coenen]

Zoek je een betere of gebruik je 'update_parsing.php' nog niet? Ik gok het eerste.
BTW, de releases zijn wel dingen die wilt hebben? Er was een tijd dat dit vaak Duitse releases waren.

[Henkske]

Idd het eerste.
Veel TVSHOWS in de ETC map hebben een numerieke releasename terwijl de inhoud van de rars de juiste benaming heeft. Ik weet dat het mogelijk is om deze om te zetten middels een aparte parsing script maar ik het het zelf nog niet gevonden.

In ieder geval bedankt voor je reply:)

[Buzzie]

@Henkske:

Heb je de update_parsing.php ook aangepast?? Dit is namelijk wel nodig.....OOK na elke update van het bestand. Standaard doet hij alleen een echo wat hij kan aanpassen ipv het daadwerkelijk uitvoeren.

Daarnaast.....kijk ook even op de on officiele forum van newznab op newznabforums.com en zoek naar misc_sorter van ugo

[Henkske]

@ Buzzie,

Bedankt voor je reactie. Ik zal es gaan kijken naar de misc_sorter.

Het update_parsing heb ik uiteraard aangepast:)