TorrentFlux 2.1-b4rt [Current: 2.1-b4rt-98]

[b4rt]

moved...

since version 2.1-b4rt-94 this version is moved to :

https://tf-b4rt.berlios.de/

Do you plan to update tf-b4rt with TF2.3 as a base?

the old 2.1-branch of tf-b4rt (2.1-b4rt-xxx) is not actively developed (only fixes, minors and updates) but should be still an alternative for official 2.2/2.3.
all things from the changelogs of 2.2/2.3 are ported to both tfb-branches (except the image-vali which is only in torrentflux-b4rt but there in an extended implementation)
so old branch has "all" (except the image-vali) from 2.2/2.3 already in v98.

"torrentflux-b4rt" (which will be renamed to a real different name before going final) is a new thing and has nothing to do with the official tf-lines. only thing you can do is upgrade from official tfs to torrentflux-b4rt (check the INSTALL-doc how to do that). just check out the latest alpha, its installed "in a minute" (web-based setup + upgrade).

[toolmanwill]

i will experiment around with maketorrent now and see if i can find anything out.
oh btw is it a file or a dir you are making the torrent from ?

EDIT: what options did you use ?
priavte yes/no ?
DHT support enabled ?

EDIT: i just mad a torrent from a dir with default-settings.. no problem.
pls tell me more about creation (options / dir or file etc) i dont want to test every combination.

regards,
b4rt

made a private torrent, for a directory. no dht

[b4rt]

made a private torrent, for a directory. no dht

having the same problem here. afaic this is a bug either in btmakemetafile.py or inside tornado-code itself. (so this is present in every tf 2.1 i assume)
to solve this further research/testing is needed... any help welcome.
i wont priorize this high as i want to fix other things first. (-> its on hold for me now)

regards,
b4rt

[b4rt]

further looked into the transmission-client-totals-bug...

do (not sure yet how to reproduce it but a restart is involved)
-> the values doubled on client-start.

easy to reproduce i found out. just restart a torrent ran by transmission and watch totals after restart in downloaddetails. they doubled every restart in my tests.

i noticed something there too but only on transmission-clients.
sometimes it seems the values are added when they shouldnt. but this is only the case since last upgrade of transmissioncli.

i downgraded transmission step by step and this problem is present in all 0.6-svn versions of transmissioncli. its even present in 0.5 which really makes me wonder why it ever worked with transmission-clients as there is nothing client-specific in my totals-code. totals-safe is called in the ClientHandler-baseclass with the same code for all clients.

just found the cause for this issue. transmission is behaving different as tornado on restart. while tornado always flushes his totals-stats and has always 0 for up and 0 for down after a start transmission "remembers" what it has already transferred.
my code is written for the "tornado"-behaviour of "not-remembering transfer-stats" so it behaves bogus on transmissionclients.
update as soon as i have a elegant solution for this in mind/implemented.

EDIT:
this behaviour of transmission-clients also affects xfer-hack as xfer-hack does the same like my totals code (pull stats from stat-file on client-start, process em and safe values to the database).
this means if you restart transmission-clients you will have wrong xfer-stats as well.

the more your transmission-clients have already transferred, the bigger your errors will be (not double like i stated, thats only the case at the begin when you "restart quick")

must admit this is more a ***** than i first thought. after reviewing and rethinking things i wonder we did not have more issues based in the behaviour of transmission-clients so far because this affects all code using the fields uptotal and downtotal of a stat-file from a transmissioncli. (xfer, torrent totals, share-kill)
as this is not just a "wrong" value at point x but a permanent different behaviour while the client is up there is no "simple" solution for this.
as quick-hack-patch i tried to delete transmissionclis resume-files (i hoped transmissioncli pulls his transfer-totals-values from there on start) which did not work. afaic transmission really recalcs the values from the data all the time which is complete different compared to tornado in code-logic in some parts (eg when clients are calcing their share-kill)

the only solution (except hacking lib-transmission to emulate tornado which i absolute discourage) i can think of now is to move the data + accesses and totals-calc-logic (-> share-kill calc logic) into the ClientHandler-classes and have different implementations for the different clients.
after having all the fields and logic encapsulated in the clienthandlers it would be required to rewrite all code in tf (?), hacks (xfer, ?) and my code ( totals, share-kill, ? ) to not access the fields direct anymore, do any calc-stuff direct anymore , etc...

ok.. i got a solution for this problem implemented. all tests so far succeeded and things look like they are working as they should now with all clients.

about the solution
i have extended ClientHandler-API to encapsulate how a particular torrent-clients holds and calcs his transfer-values so that different clients with different behaviour on this can be used transparent "inside flux code" (outside ClientHandler classes).
all code (including totals, sharekill, dl-details, xfer) accessing stat-files-values for transfer direct is replaced with calls to new functions which proxy the calls to the ClientHandler-methods. (this is not nec. but i did this so i needed to rewrite less code)
the new methods in the ClientHandler-interface are :

Code:

    /**
     * gets current transfer-vals of a torrent
     *
     * @param $db ref to db-object
     * @param $torrent
     * @return array with downtotal and uptotal
     */
    function getTorrentTransferCurrent(&$db, $torrent)  { return; }

    /**
     * gets total transfer-vals of a torrent
     *
     * @param $db ref to db-object
     * @param $torrent
     * @return array with downtotal and uptotal
     */
    function getTorrentTransferTotal(&$db, $torrent) { return; }

about the implementation

tornado :
tornado writes transfer-totals of current session to the stat-file. tornado does not remember or recalc what it has already transferred of a torrent in last sessions.

• current transfer :
  stat-files are accessed and values are pulled from there.
• total transfer
  stat-files are accessed and values are pulled from there. the saved values (from previous tornado-client-sessions) are pulled from the database and added to current transfer-totals.
  

transmission :
transmission writes total transfer to the stat-file. transmission does recalc what it has already transferred of a torrent (-> so it also "remembers" what it has done over client-restarts).

• current transfer :
  stat-files are accessed and values are pulled from there. after this values from previous sessions are loaded from the database and substracted from the values of the stat-files.
• total transfer
  stat-files are accessed and values are pulled from there.
  

regards,
b4rt

[b4rt]

update v85.

note : if you are using transmission-clients you really should do an upgrade to v85, especially if you have xfer-hack enabled.

this time the tarball-content is tested on a fresh vhost on an unbuffered and ultra-talky php-setup to be sure nothing is wrong

changelog :

Code:

- fixed transmission-transfer-values problem.
  http://www.torrentflux.com/forum/index.php/topic,1265.msg11508.html#msg11508

- checked most code on a ultra-talky (printing out notices) and unbuffered php
  and modified all code i found to be "clean" or suppressed the notices in some
  cases where its "safe and ok" to ignore them.

- dereferrer-hack. if hack is enabled links in links-list and private messages
  are proxied over new page dereferrer.php to remove referrers.

- hyperlinks for http-link-strings in private messages.

- "Start"-checkbox enhanced to "instant-action" dropdown. its now possible to
  choose if new torrent(s) should be started or queued automatic after upload/
  download.

- order of dropdown and bulk-operations changed. additional entry which is
  the default-selection is a dummy. (no "accident-operations" any more ~)

have fun,
b4rt

[CrazyCanuck]

This Version : 2.1-b4rt-84

Available Version : 2.1-b4rt-84

This Version looks good.

Any ideas why it still shows 84 and not 85? My other client on my home machine updated fine, my telehoused doesn't.

[b4rt]

This Version : 2.1-b4rt-84

Available Version : 2.1-b4rt-84

This Version looks good.

Any ideas why it still shows 84 and not 85? My other client on my home machine updated fine, my telehoused doesn't.

not really, even if dns of telehoused is lazy there is no way to fetch old version-string. a lazy proxy with old content maybe... but i cant imagine that.
try again pls (some hours passed now) and if you keep gettin it do a manual upgrade pls.

regards,
b4rt

[mb.Tab]

Okay update + dereferer works great, thanks again

[CrazyCanuck]

This Version : 2.1-b4rt-84

Available Version : 2.1-b4rt-84

This Version looks good.

Any ideas why it still shows 84 and not 85? My other client on my home machine updated fine, my telehoused doesn't.

not really, even if dns of telehoused is lazy there is no way to fetch old version-string. a lazy proxy with old content maybe... but i cant imagine that.
try again pls (some hours passed now) and if you keep gettin it do a manual upgrade pls.

regards,
b4rt

Thanks B, all working now, not sure why it wasn't working before though.

[mrgreaper]

a new glitch

i deleted my htmlfolder
i droped my torrent flux database
to be safe i created a new one called tflux so no chance of database infection from prevouse installs
i imported the torrent flux sql file (the one included in your most recent release)
i edited config file as instructed
i went to the page logged in (creating the user in the process)
went through all the options
could veiw main page no problems
clicked admin
clicked queue to set that up the folder was wrong for tfgmrg and sense theres no update button i figured i``d copy the tfgmrg file to that location so i did that (as root)
but the torrent flux had frozen
restarted server machine
torrentflux working clicked admin clicked queue the green light was on but still no options for size of queue etc
and torrentflux froze again
i have attached a jpg screen shot of it

by froze i mean you can no longer view any other torrent flux pages all other webpages hosted on the server work but all torrent flux ones dead
i have done a mysqlcheck the database seems fine (11 tables)

[b4rt]

a new glitch

i deleted my htmlfolder
i droped my torrent flux database
to be safe i created a new one called tflux so no chance of database infection from prevouse installs
i imported the torrent flux sql file (the one included in your most recent release)
i edited config file as instructed
i went to the page logged in (creating the user in the process)
went through all the options
could veiw main page no problems
clicked admin
clicked queue to set that up the folder was wrong for tfgmrg and sense theres no update button i figured i``d copy the tfgmrg file to that location so i did that (as root)
but the torrent flux had frozen
restarted server machine
torrentflux working clicked admin clicked queue the green light was on but still no options for size of queue etc
and torrentflux froze again
i have attached a jpg screen shot of it

by froze i mean you can no longer view any other torrent flux pages all other webpages hosted on the server work but all torrent flux ones dead
i have done a mysqlcheck the database seems fine (11 tables)

sounds like a deadlock on a pipe. your pages are trying to read from / write to a dead pipe so they will hang forever.
dunno how you made it that this could happen but to fix it you have to (easiest way ~) :

• stop all torrents (if even fluxcli.php is not working shoot em with kill (-9))
• shoot all tfqmgr.pl processes that are running if there are any. (maybe they need -9 too)
• use repair-function of fluxcli.php (this will also fix tfqmgr.pl-pipes)

EDIT: if you ever have done anything with tfqmgr.pl as root there now may be permission-problems as well. check this dir and ensure its owned by webserver-user / is writable for webserver-user (default-path) :
/usr/local/torrent/.tfqmgr/

EDIT2: there is a typo in your screenie (a q is a g) which may be the reason you had to copy tfqmgr as this is not needed normal. (-> may be the reason that screwed up your flux)

regards,
b4rt

[mrgreaper]

ok im not a very linux person
i dont know how to bring up task manager on linux (i know i hang my head in shame)
however it does  un freeze after restarting the machine so long as you avoid the queue page

i still tried going to fluxcli.php (after stoping the downloads)

but it just displays a white page displaying #!/usr/bin/php

as regards permisions
the user name i use for the database is root so that should be ok? (really not to familier with permissions)

going to admin > superadmin > tfgmgr>status also causes the freeze



**edit** nope the typo is my dyslexia the folder is called tfqmgr in /srv/www/htdocs/tf/
it is the contents of the html extracted
i have never edited the tfqmgr.pl file im not that brave lol
if i delete the /.tfqmgr/ folder will the system make another?

[b4rt]

ok im not a very linux person
i dont know how to bring up task manager on linux (i know i hang my head in shame)
however it does  un freeze after restarting the machine so long as you avoid the queue page

try this (this is the hard but easy way and will kill _all_ python + transmissions):

Code:

killall -9 python
killall -9 transmissioncli

same method may be used to kill tfqmgrs running but if your system has running perl-processes you dont want to kill ... dont use it :

Code:

killall -9 perl

i still tried going to fluxcli.php (after stoping the downloads)
but it just displays a white page displaying #!/usr/bin/php

you have php-cli ?
you may also try this in the dir where fluxcli.php is:

Code:

php fluxcli.php repair

if i delete the /.tfqmgr/ folder will the system make another?

yes, tfqmgr.pl checks for that dir on start so if you delete the dir it will recreate it. another easy way to remove leftovers of tfqmgr.pl. (be aware that you will also delete tfqmgrs log with this)

regards,
b4rt

[mrgreaper]

php fluxcli.php repair worked a treat i now have a much bigger admin ->queue page

thank you

[b4rt]

php fluxcli.php repair worked a treat i now have a much bigger admin ->queue page

thank you

if your box is rebooted sometimes adding "fluxcli.php repair" to your startup scripts may not be a bad idea as it ensures "flux is not messed up" after your system booted.

EDIT: oh btw what i forgot... in tfqmgr.pl revision 1.25 its required that fluxcli.php can be executed as its not started with "php fluxcli.php" but with "./fluxcli.php".
there are some more things (starting fluxcli.php with "php fluxcli.php", making it possible to change queue-manager-settings without need to restart daemon,...) i wanted to tune in tfqmgr.pl but i have em all delayed atm as tfqmgr.pl cant be updated via superadmin (so its delayed for v9xx versions (tarball upgrade required))

regards,
b4rt

[toolmanwill]

made a private torrent, for a directory. no dht

having the same problem here. afaic this is a bug either in btmakemetafile.py or inside tornado-code itself. (so this is present in every tf 2.1 i assume)
to solve this further research/testing is needed... any help welcome.
i wont priorize this high as i want to fix other things first. (-> its on hold for me now)

regards,
b4rt

Thank you for you quick responses! We reinstalled using v85 and it works now, go figure.
One thing i did notice when opening one of the corrupted torrent files in notepad is that an entire blank line was at top of file, which is not normally there. When I made one with v85 the blank line was gone and all is well.

Thanx for your help again!!

Will