svn 1528

Unfortunately it is still behaves the same.
I changed the settings to:

Maximum number of total threads: 2   
Maximum number of NNTP connections: 1   
Max threads per download: 1   
Maximum database intensive threads:    2

The problem starts when a header-fetch phase ends and the generate-sets phase starts. Before this phase, there is only one thread running (i.e. header-fetch), which leaves the other free thread to handle the make_nzb. After this phase, another header-fetch starts for the next group, which shows 2 threads running on the activity monitor. The problem occurs during this phase. A new make_nzb thread gets re-queued, even after the other 2 threads finish.

I put up a log file: urdlog_20100516_1047.zip
nzb 18, 19 and 20 keep re-queing.

I can't reproduce it with the max-treads set to 4, how hard I bombard it with MAKE_NZBs - it works flawlessly.
I switched back to a setting of 2 and got it again. The logfile is called:
urdlog_20100514_2249.zip
MAKE_NZB 102, 103 and 104 are re-queing.
Did't get the MAKE_NZB canceled note (I stopped it with a logfile of 20MB).
Did you remove the too many re-queing, canceling make_nzb thingy? 

At a certain moment all updating tasks had finished and only the MAKE_NZB 68/69/70 tasks kept re-queuing.

I increased the max nr of total threads from 2 to 4.

-

svn 1503
I'm still getting 'Item queued too often, task cancelled: MAKE_NZB 53' notices (too many actually) and have a hard time finding out which of the nzb's was actually canceled. There is no apparent relation between '53' and the actual nzb-file-name I asked to make, so re-initiating the make-nzb-file is a problem.

Why is the MAKE_NZB being re-queued? Due to some lock?
Why in 2 phases and (fetch data / make_nzb)? Can it be done in one or give the 'MAKE_NZB ##' a nzb-file relate name?
 

Its always. I just updated the db again:
alter table downloadinfo add column `subdl` tinyint(10) default 0 not null;

I purged the a.b.m.cooking and updated again. Still the 'waited too long error' and urdd shutdown.

Perhaps the upatedb doesn't work and I need to re-build the db from scratch?

Edit:
I removed the .installed and rebuild the db. It works fine now.
Sorry for the harassment

I noticed something odd though:
'import all settings' resulted in log-in window again. After logging in again, the newsgroup list was not imported. I could however import the 'urd_all_settings' into the Subscriptions>Newsgroups>import groups.

I just noticed that the urdd was offline.
I'm on 1492. Restarting seemed no issue.
Has the DB changed? - do I need updating?

Edit:
It crashed while generating an nzb file with a message window after 2s: 'waited too long'

May 09 19:15:41 DebNAS urdd: DEBUG fn:do_diskfree() pid:14559 (9175040 9175040)May 09 19:15:41 DebNAS urdd: DEBUG read line: [DISKFREE p1]May 09 19:15:41 DebNAS urdd: DEBUG fn:do_diskfree() pid:14559 (9175040 9175040)May 09 19:15:45 DebNAS urdd: DEBUG Incoming connection from host localhost:36688May 09 19:15:45 DebNAS urdd: DEBUG read line: [USER Reab4]
May 09 19:15:45 DebNAS urdd: DEBUG read line: [PASS XXX]
May 09 19:15:45 DebNAS urdd: DEBUG read line: [DISKFREE h]
May 09 19:15:45 DebNAS urdd: DEBUG fn:do_diskfree() pid:14559 (9175040 9175040)
May 09 19:15:45 DebNAS urdd: DEBUG read line: [DISKFREE p1]
May 09 19:15:45 DebNAS urdd: DEBUG fn:do_diskfree() pid:14559 (9175040 9175040)
May 09 19:15:49 DebNAS urdd: DEBUG Incoming connection from host localhost:36689May 09 19:15:49 DebNAS urdd: DEBUG read line: [USER Reab4]
May 09 19:15:49 DebNAS urdd: DEBUG read line: [PASS XXX]
May 09 19:15:49 DebNAS urdd: DEBUG read line: [DISKFREE h]
May 09 19:15:49 DebNAS urdd: DEBUG fn:do_diskfree() pid:14559 (9175040 9175040)
May 09 19:15:49 DebNAS urdd: DEBUG read line: [DISKFREE p1]
May 09 19:15:49 DebNAS urdd: DEBUG fn:do_diskfree() pid:14559 (9175040 9175040)
May 09 19:15:52 DebNAS urdd: DEBUG Incoming connection from host localhost:36690
May 09 19:15:52 DebNAS urdd: DEBUG read line: [USER Reab4]
May 09 19:15:52 DebNAS urdd: DEBUG read line: [PASS XXX]
May 09 19:15:52 DebNAS urdd: DEBUG read line: [MAKE_NZB]
May 09 19:15:52 DebNAS urdd: DEBUG fn:create_make_nzb() pid:14559 (9175040 9175040)
May 09 19:15:52 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 19:15:52 DebNAS urdd: CRITICAL An error occured during startup of URD daemon: Could not execute SQL query "INSERT INTO downloadinfo ("name", "unpar", "unrar", "subdl", "delete_files", "status", "destination", "username", "preview", "size", "first_run") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)" Could not execute SQL query "INSERT INTO downloadinfo ("name", "unpar", "unrar", "subdl", "delete_files", "status", "destination", "username", "preview", "size", "first_run") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)" mysql error: [1054: Unknown column 'subdl' in 'field list'] in EXECUTE("INSERT INTO downloadinfo ("name", "unpar", "unrar", "subdl", "delete_files", "status", "destination", "username", "preview", "size", "first_run") VALUES ('', 0, 0, 0, 0, 0, '', 'Reab4', 3, 0, 1)")
May 09 19:15:52 DebNAS urdd: CRITICAL
May 09 19:15:52 DebNAS urdd: NOTICE is there another URD daemon running?
May 09 19:15:52 DebNAS urdd: DEBUG #0 /usr/share/urd_svn/urdd/download_functions.php(430): DatabaseConnection->insert_query('downloadinfo', Array, Array)
May 09 19:15:52 DebNAS urdd: DEBUG #1 /usr/share/urd_svn/urdd/do_functions.php(316): add_download(Object(DatabaseConnection), 'Reab4', 0, 0, 0, 0, 0, '', 3)
May 09 19:15:52 DebNAS urdd: DEBUG #2 /usr/share/urd_svn/urdd/urdd_command.php(165): create_make_nzb(Object(DatabaseConnection), Object(server_data), 'Reab4', 49)
May 09 19:15:52 DebNAS urdd: DEBUG #3 /usr/share/urd_svn/urdd/urdd.php(452): do_command(Object(DatabaseConnection), 'MAKE_NZB', '', Object(conn_list), Resource id #23111, Object(server_data), NULL, NULL, false)
May 09 19:15:52 DebNAS urdd: DEBUG #4 /usr/share/urd_svn/urdd/urdd.php(536): read_sockets(Object(DatabaseConnection), Array, Array, Object(conn_list), Object(server_data))
May 09 19:15:52 DebNAS urdd: DEBUG #5 /usr/share/urd_svn/urdd/urdd.php(875): server(Array, Object(DatabaseConnection), Object(server_data))
May 09 19:15:52 DebNAS urdd: DEBUG #6 {main}
May 09 19:15:52 DebNAS urdd: ERROR Exception: Could not execute SQL query "SELECT "value" FROM preferences WHERE "option" = 'urdd_startup' AND "userID" = 0" mysql error: [2006: MySQL server has gone away] in EXECUTE("SELECT "value" FROM preferences WHERE "option" = 'urdd_startup' AND "userID" = 0 LIMIT 2147483647")
May 09 19:15:52 DebNAS urdd: ERROR
May 09 19:15:52 DebNAS urdd: DEBUG fn:shutdown_handler() pid:14559 (9175040 9175040)
May 09 19:15:52 DebNAS urdd: INFO shutdown handler called as parent

I had this problem again.
Second paragraph show a part of the raw log. The log is rather long: 276MB. (Looks like there is no rotation) 


09 May 2010    17:35:21    DEBUG    fn:do_cancel_all() pid:21130 (9961472 10223616)
09 May 2010    13:57:36    NOTICE    Item queued too often, task cancelled: MAKE_NZB 39
09 May 2010    13:57:36    DEBUG    updating status Cancelled
09 May 2010    13:57:36    DEBUG    updating status Cancelled
09 May 2010    13:57:36    NOTICE    Item queued too often, task cancelled: MAKE_NZB 40
09 May 2010    13:57:36    NOTICE    Item queued too often, task cancelled: MAKE_NZB 38
09 May 2010    13:57:36    DEBUG    updating status Cancelled
09 May 2010    13:57:36    DEBUG    updating status Cancelled
09 May 2010    13:57:36    NOTICE    Item queued too often, task cancelled: MAKE_NZB 41
09 May 2010    13:57:36    NOTICE    Item queued too often, task cancelled: MAKE_NZB 42
09 May 2010    13:57:36    DEBUG    updating status Cancelled
08 May 2010    14:36:13    NOTICE    Item queued too often, task cancelled: MAKE_NZB 34
08 May 2010    14:36:13    DEBUG    updating status Cancelled
08 May 2010    14:36:13    DEBUG    updating status Cancelled
08 May 2010    14:36:13    NOTICE    Item queued too often, task cancelled: MAKE_NZB 35
08 May 2010    14:36:13    NOTICE    Item queued too often, task cancelled: MAKE_NZB 33
08 May 2010    14:36:13    DEBUG    updating status Cancelled
08 May 2010    14:36:13    DEBUG    updating status Cancelled
08 May 2010    14:36:13    NOTICE    Item queued too often, task cancelled: MAKE_NZB 36
08 May 2010    14:36:13    NOTICE    Item queued too often, task cancelled: MAKE_NZB 37

May 09 13:57:36 DebNAS urdd: NOTICE Item queued too often, task cancelled: MAKE_NZB 38
May 09 13:57:36 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 13:57:36 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 13:57:36 DebNAS urdd: DEBUG updating status Running
May 09 13:57:36 DebNAS urdd: DEBUG worker forked: PID 27323
May 09 13:57:36 DebNAS urdd: DEBUG fn:queue_delete() pid:21130 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG fn:handle_queue_item() pid:27323 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG fn:do_make_nzb() pid:27323 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG Dl still locked, sleeping
May 09 13:57:36 DebNAS urdd: DEBUG fn:shutdown_handler() pid:27323 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG shutdown handler called as child
May 09 13:57:36 DebNAS urdd: DEBUG Child exited (rc: 14)
May 09 13:57:36 DebNAS urdd: DEBUG Thread status 1; server: 0
May 09 13:57:36 DebNAS urdd: DEBUG Dl still locked, pausing
May 09 13:57:36 DebNAS urdd: DEBUG Queueing MAKE_NZB 39
May 09 13:57:36 DebNAS urdd: DEBUG updating status Cancelled
May 09 13:57:36 DebNAS urdd: NOTICE Item queued too often, task cancelled: MAKE_NZB 39
May 09 13:57:36 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 13:57:36 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 13:57:36 DebNAS urdd: DEBUG updating status Running
May 09 13:57:36 DebNAS urdd: DEBUG worker forked: PID 27324
May 09 13:57:36 DebNAS urdd: DEBUG fn:queue_delete() pid:21130 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG fn:handle_queue_item() pid:27324 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG fn:do_make_nzb() pid:27324 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG Dl still locked, sleeping
May 09 13:57:36 DebNAS urdd: DEBUG fn:shutdown_handler() pid:27324 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG shutdown handler called as child
May 09 13:57:36 DebNAS urdd: DEBUG Child exited (rc: 14)
May 09 13:57:36 DebNAS urdd: DEBUG Thread status 1; server: 0
May 09 13:57:36 DebNAS urdd: DEBUG Dl still locked, pausing
May 09 13:57:36 DebNAS urdd: DEBUG Queueing MAKE_NZB 40
May 09 13:57:36 DebNAS urdd: DEBUG updating status Cancelled
May 09 13:57:36 DebNAS urdd: NOTICE Item queued too often, task cancelled: MAKE_NZB 40
May 09 13:57:36 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 13:57:36 DebNAS urdd: DEBUG Connecting to mysql @ localhost
May 09 13:57:36 DebNAS urdd: DEBUG updating status Running
May 09 13:57:36 DebNAS urdd: DEBUG worker forked: PID 27325
May 09 13:57:36 DebNAS urdd: DEBUG fn:queue_delete() pid:21130 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG fn:handle_queue_item() pid:27325 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG fn:do_make_nzb() pid:27325 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG Dl still locked, sleeping
May 09 13:57:36 DebNAS urdd: DEBUG fn:shutdown_handler() pid:27325 (10223616 10223616)
May 09 13:57:36 DebNAS urdd: DEBUG shutdown handler called as child
May 09 13:57:36 DebNAS urdd: DEBUG Child exited (rc: 14)
May 09 13:57:36 DebNAS urdd: DEBUG Thread status 1; server: 0

Yeah I work from svn and updated to 1487; Lets see if it happens again.
It's kinda hard to find a clue in the log.
 

Sometimes when I request it to make an nzb, it either hangs with an empty progress bar or generates no nzb. The empty progress bar is removed after an urdd cycle. The log file has a lot of 'queueing MAKE_NZB ##' in a row and sometimes a notice: 'Item queued too often, task cancelled: MAKE_NZB ##':

07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    NOTICE    Item queued too often, task cancelled: MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:22    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:21    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:21    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:21    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:21    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:21    DEBUG    Queueing MAKE_NZB 23
07 May 2010    11:15:21    DEBUG    Queueing MAKE_NZB 23

Is this due to re-shuffling of the task list or some odd behavior?

"Possibly a cross site request forgery has been carried out. If you did not send any request to this site, please cancel the action"

I've been getting these every day since day 1 I started using URD. Thought/think they are quite normal since I use 2 PCs. However, only 1 is in use while the other is on asleep. I don't log out of urd however. The annoyance is that:
 - I have absolutely no clue why the message comes at that particular moment,  in the middle of the day while I switched PCs in the morning already
 - I have no clue where/how to trace the forgery
 - The options are continue and cancel. The latter brings you back to the forgery message so continue was the only option.

How about making it optional to get these messages? Or...how are you dealing with these messages?
Do I get these because people try to log in?

I'm having problems generating a proper log, due to its size. Is the log stored in a file also?  - anyway - let me know if you need something particular.
(svn 1452)

02 May 2010    08:01:17    DEBUG    read line: [DISKFREE h]
02 May 2010    08:01:17    DEBUG    fn:do_diskfree() pid:23229 (9175040 9437184)
02 May 2010    08:01:17    DEBUG    fn:do_diskfree() pid:23229 (9175040 9437184)
02 May 2010    08:01:17    DEBUG    read line: [DISKFREE p1]
02 May 2010    08:01:14    DEBUG    #6 /usr/share/urd_svn/urdd/urdd.php(337): handle_queue_item(Object(DatabaseConnection), Object(action))
02 May 2010    08:01:14    ERROR    Error while updating alt.binaries.multimedia: Data stream not terminated with period (0)
02 May 2010    08:01:14    DEBUG    #9 {main}
02 May 2010    08:01:14    DEBUG    #5 /usr/share/urd_svn/urdd/urdd.php(139): do_update(Object(DatabaseConnection), Object(action))
02 May 2010    08:01:14    DEBUG    #8 /usr/share/urd_svn/urdd/urdd.php(876): server(Array, Object(DatabaseConnection), Object(server_data))
02 May 2010    08:01:14    DEBUG    #3 /usr/share/urd_svn/functions/nntp.class.php(386): URD_NNTP->get_headers(Array, Resource id #3202, Resource id #3204, Object(action), 1272520041, Resource id #3209, Resource id #3210, true, Resource id #3198, Resource id #3206, 1, '0')
02 May 2010    08:01:14    DEBUG    #0 /usr/share/urd_svn/functions/libs/base_nntp_client.php(1308): Base_NNTP_Client->_getTextResponse()
02 May 2010    08:01:14    DEBUG    #1 /usr/share/urd_svn/functions/libs/nntp_client.php(710): Base_NNTP_Client->cmdFastXOver('486732911-48673...')
02 May 2010    08:01:14    DEBUG    #2 /usr/share/urd_svn/functions/nntp.class.php(263): NNTP_Client->get_fast_overview('486732911', '486734910', false)
02 May 2010    08:01:14    DEBUG    updating status Failed
02 May 2010    08:01:14    DEBUG    #4 /usr/share/urd_svn/urdd/do_functions.php(692): URD_NNTP->update_newsgroup(Array, Object(action))
02 May 2010    08:01:14    DEBUG    #7 /usr/share/urd_svn/urdd/urdd.php(501): check_queue(Object(DatabaseConnection), Object(conn_list), Object(server_data))
02 May 2010    08:01:14    DEBUG    Requeueing paused
02 May 2010    08:01:14    DEBUG    Queueing UPDATE 3
02 May 2010    08:01:14    DEBUG    updating status Paused
02 May 2010    08:01:14    DEBUG    fn:disconnect() pid:29700 (13893632 13893632)
02 May 2010    08:01:14    DEBUG    NNTP Connect error received
02 May 2010    08:01:14    DEBUG    Thread status 1; server: 19
02 May 2010    08:01:14    DEBUG    fn:__destruct() pid:29700 (13893632 13893632)
02 May 2010    08:01:14    DEBUG    fn:disconnect() pid:29700 (13893632 13893632)
02 May 2010    08:01:14    DEBUG    fn:shutdown_handler() pid:29700 (13893632 13893632)
02 May 2010    08:01:14    DEBUG    shutdown handler called as child
02 May 2010    08:01:14    DEBUG    Child exited (rc: 10)
02 May 2010    08:01:13    DEBUG    read line: [PASS XXX]
02 May 2010    08:01:13    DEBUG    read line: [USER Reab4]
02 May 2010    08:01:13    DEBUG    read line: [DISKFREE h]

01 May 2010    19:20:09    DEBUG    #6 /usr/share/urd_svn/urdd/urdd.php(337): handle_queue_item(Object(DatabaseConnection), Object(action))
01 May 2010    19:20:09    DEBUG    #5 /usr/share/urd_svn/urdd/urdd.php(139): do_update(Object(DatabaseConnection), Object(action))
01 May 2010    19:20:09    DEBUG    #7 /usr/share/urd_svn/urdd/urdd.php(501): check_queue(Object(DatabaseConnection), Object(conn_list), Object(server_data))
01 May 2010    19:20:09    DEBUG    #8 /usr/share/urd_svn/urdd/urdd.php(876): server(Array, Object(DatabaseConnection), Object(server_data))
01 May 2010    19:20:09    DEBUG    #9 {main}
01 May 2010    19:20:09    DEBUG    #4 /usr/share/urd_svn/urdd/do_functions.php(692): URD_NNTP->update_newsgroup(Array, Object(action))
01 May 2010    19:20:09    ERROR    Error while updating alt.binaries.mom: Data stream not terminated with period (0)
01 May 2010    19:20:09    DEBUG    updating status Failed
01 May 2010    19:20:09    DEBUG    #0 /usr/share/urd_svn/functions/libs/base_nntp_client.php(1308): Base_NNTP_Client->_getTextResponse()
01 May 2010    19:20:09    DEBUG    #1 /usr/share/urd_svn/functions/libs/nntp_client.php(710): Base_NNTP_Client->cmdFastXOver('794754714-79475...')
01 May 2010    19:20:09    DEBUG    #2 /usr/share/urd_svn/functions/nntp.class.php(263): NNTP_Client->get_fast_overview('794754714', '794756713', false)
01 May 2010    19:20:09    DEBUG    #3 /usr/share/urd_svn/functions/nntp.class.php(386): URD_NNTP->get_headers(Array, Resource id #144396, Resource id #144399, Object(action), 1272300988, Resource id #144404, Resource id #144405, true, Resource id #144393, Resource id #144401, 1, '0')
01 May 2010    19:20:09    DEBUG    Queueing UPDATE 7293
01 May 2010    19:20:09    DEBUG    Thread status 1; server: 19
01 May 2010    19:20:09    DEBUG    NNTP Connect error received
01 May 2010    19:20:09    DEBUG    Requeueing paused
01 May 2010    19:20:09    DEBUG    updating status Paused
01 May 2010    19:20:09    DEBUG    Child exited (rc: 10)
01 May 2010    19:20:09    DEBUG    fn:disconnect() pid:6175 (13893632 13893632)
01 May 2010    19:20:09    DEBUG    fn:__destruct() pid:6175 (13893632 13893632)
01 May 2010    19:20:09    DEBUG    shutdown handler called as child
01 May 2010    19:20:09    DEBUG    fn:disconnect() pid:6175 (13893632 13893632)
01 May 2010    19:20:09    DEBUG    fn:shutdown_handler() pid:6175 (13893632 13893632)
01 May 2010    19:20:07    DEBUG    read line: [PASS XXX]
01 May 2010    19:20:07    DEBUG    Incoming connection from host localhost:60063
01 May 2010    19:20:07    DEBUG    read line: [DISKFREE h]
01 May 2010    19:20:07    DEBUG    read line: [USER Reab4]
01 May 2010    19:20:07    DEBUG    read line: [DISKFREE p1]
01 May 2010    19:20:07    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:20:07    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:20:03    DEBUG    read line: [USER Reab4]
01 May 2010    19:20:03    DEBUG    read line: [PASS XXX]
01 May 2010    19:20:03    DEBUG    Incoming connection from host localhost:60062

01 May 2010    19:16:47    DEBUG    Incoming connection from host localhost:59985
01 May 2010    19:16:47    DEBUG    read line: [DISKFREE h]
01 May 2010    19:16:47    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:47    DEBUG    read line: [DISKFREE p1]
01 May 2010    19:16:47    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:43    DEBUG    read line: [PASS XXX]
01 May 2010    19:16:43    DEBUG    read line: [USER Reab4]
01 May 2010    19:16:43    DEBUG    Incoming connection from host localhost:59984
01 May 2010    19:16:43    DEBUG    read line: [DISKFREE h]
01 May 2010    19:16:43    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:43    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:43    DEBUG    read line: [DISKFREE p1]
01 May 2010    19:16:41    WARNING    Cannot get messages:
01 May 2010    19:16:41    DEBUG    fn:disconnect() pid:6175 (13893632 13893632)
01 May 2010    19:16:41    ERROR    Data stream not terminated with period (0)
01 May 2010    19:16:39    DEBUG    read line: [PASS XXX]
01 May 2010    19:16:39    DEBUG    Incoming connection from host localhost:59981
01 May 2010    19:16:39    DEBUG    read line: [DISKFREE h]
01 May 2010    19:16:39    DEBUG    read line: [USER Reab4]
01 May 2010    19:16:39    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:39    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:39    DEBUG    read line: [DISKFREE p1]
01 May 2010    19:16:35    DEBUG    read line: [PASS XXX]
01 May 2010    19:16:35    DEBUG    Incoming connection from host localhost:33773
01 May 2010    19:16:35    DEBUG    read line: [DISKFREE h]
01 May 2010    19:16:35    DEBUG    read line: [USER Reab4]
01 May 2010    19:16:35    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:35    DEBUG    fn:do_diskfree() pid:21719 (9175040 9175040)
01 May 2010    19:16:35    DEBUG    read line: [DISKFREE p1]
01 May 2010    19:16:31    DEBUG    read line: [PASS XXX]

There are more instances in the log but they may be caused by me killing tasks. I had problems with the multimedia group hanging while updating. This is not a large group and since it, together with the boneless update, was blocking updates for other groups for 10h, I killed the task. It autostarted and hung again at 73% so I killed it again and purged the group, which took quite a while but finished eventually. It re-fetched headers and it quit with the period (0) error. I manually restarted it and now seems ok.
I can't make heads or tails of this behavior - perhaps just a one-time glitch.

Do you know what this means:
Error while updating alt.binaries.multimedia: Data stream not terminated with period (0)

Error in the database or while fetching headers?

indeed. Forget it, seems no issue in Opera.

If I download a file from the ViewFiles>Downloads section, a firefox download window opens and starts the download. During the download, firefox is not able to (auto)refresh other tabs as activity in the urd tab is preventing this. Pressing ESC in the urd tab releases the lock. I noticed this as my server upload speed is only ~100kB/s; it takes a while (~4mins) to download a 20MB file.
Is there a way to kind of auto-release the lock?

If I enable it I get error(or warning) 500 from eweka so they probably don't support it.
It is already a while ago and haven't tried it since.

All confirmed. Thanks!

[EportAllSettings]

3 - Admin>control>EportAllSettings sounds like an export of all URD settings, including server list, group list and user settings.
If it's true, then it saves under the same (default) name as Admin>Configuration:
urd_config.xml. Perhaps change the default name to reflect the AllSettings.

Ah you paid the bills again

svn 1447, noticed so far:

1 - in log page, log file level set per default doesn't follow the admin>config setting
2 - can not import server settings; import button yields no response
3 - importing all settings from the admin>control page yields 'No valid action found.'
4 - I downloaded a file from ViewFiles>Downloads. It prepends the filename with an '_'
5 - after the 4 download I lost connection with the server
6 - recovered after a while

I noticed an update_db for 1.0.4 to 1.0.5 in svn (1437?). Do I need to run something to get it working?. I'm still at 1423 (i think). I'm at work now, can't hack.
How do I manually update the db again?

After I moved the mysql DB to hdc I have not had a single hickup. Expire is up to 5 days and boneless has had 20MB of data. Surely gathering/processing all the data takes some time but the processing itself doesn't cause problems.
Thankyou very much for clearing the view.

The system is a 2.6GHz hyperthreading with 1GB RAM. It's already an oldy but suits me well for now. Consumption is 55~85W 24/7. You can see stats at 85.146.213.173. The system load is 6.5 when DL/rar/par and urd-handling, which is a bit high.

I just changed the mysql DB to hdc and upped the expiration to 3 days. Lets see how it behaves.

I still don't fully grasp the (2) setting. If (1) default expiration (or individual group expiration) is set to 1, then how will (2), set to 4, will have any effect. I.e. all>1day will be deleted due to (1), right?

There is also a "Expire time for incomplete sets (in days, 0 to disable): " setting. It overrides the (1) and (2) setting?

Many thanks for explaining.   

hmm  , indeed sounds like a system performance issue. It is anyway good to hear that it is not reproducible on your side. It doesn't surprise me, if I think of it, since running a proper 1080p from hda has not been doable even before urd was installed. hellanzb/rar/par caused too much disk activity.
I have all located on hda (=also / disk) , just to put hdc and hdd to sleep after 30mins.
l may run an experiment to have mysql on hdc for a while.

What about the 4 days expiration setting? How is this reflected by what the user can see?
With the settings I kind of expected:
    get-1-day-old-headers -> store in 4-day-history-database

I've kind of come to a best solution to dealing with large groups:

(1)
"Default expire time (in days): "     =1
This is the how many days of headers it will initially collect.

(2)
"Age of removed files: "      =4   (was 8 )
"Age of volatile database info :"    =4   (was 8 )
Setting this lower yields a much lower and manageable database. Boneless ~5MB  (was>12MB)

(3)
"Expire after update: "      no  (un-tick)
With large groups and (3) ticked, the exipiration phase causes urd to become unresponsive. In firefox the urd page is not loading and causes other tabs not to load as well. This can be unlocked by pressing ESC un the urd tab. Even with this un-ticked, processing the large groups takes some time and can cause urd to become unresponsive - you just have to wait. I also set the autoupdate of large groups to 3 hours, starting at 0:50 and the smaller ones to 1 hour, starting at 0:00.

(4)
Since (3) is unticked, I:
"Optimise database:"     daily
"Clean database of volatile information : "   daily



From (2) I would expect that the database contains data from up to 4 days old. I can't find data>1day however. Is this normal?