Sweeper not running [SOLVED]

[prpr]

it would would be nice to change the start and and end of run log entries to level 0 so that there was some evidence of it running

Give us a sample message so we know where to start the search! Or a patch, or anything.

 

[Black Hole]

Presumably in a log file?

Yes, in the auto.log with full debug, at the start of the sweeper run. It's not a harmful message, just reporting there's no .conf, but the conundrum is that before your fix it would never have been recorded.

A bit more context is useful.

The context is the continuing discussion!

 

[MymsMan]

Give us a sample message so we know where to start the search! Or a patch, or anything.

see https://hummy.tv/forum/threads/sweeper-not-running-solved.10568/post-161433 the first and last messages in the previously quoted verbose log file

 

[prpr]

the first and last messages in the previously quoted verbose log file

They're produced by the WebIf framework, rather than Sweeper itself. I doubt you'd want all the plugins logging start/stop constantly at debug level 0.

 

[Black Hole]

I thought it wasn't running because the folder in question has the "[" prefix

I have now determined that the "[" is not an impediment, at least not for local sweeper rules. Not sure about global rules...

 

[Black Hole]

13/04/2022 19:42:04 - Error opening sweeper ruleset (/mod/etc/sweeper.conf), /mod/etc/sweeper.conf: No such file or directory

Hmm. I've dropped the logging level down to actions and errors only, and the aforementioned log message continues to report on each auto run (expected, being an "error"). Can it be downgraded to a warning rather than an error?

I'll find out whether a sweeper rule match triggers an action message later...

 

[prpr]

Update to the latest version, 2.2.5-2. I've dropped the error message, as it's pointless too.

 

[Black Hole]

I'll find out whether a sweeper rule match triggers an action message later...

It does. What the sweeper action messages are not doing in the log is introducing themselves as from sweeper:

1490    14/04/2022 10:34:26 - mp3:          Converting... MPEG-1 Audio Layer III (MP3)
1489    14/04/2022 10:34:26 - mp3:     MP3: /mnt/hd2/My Video/[MP3]/20211004
1488    14/04/2022 10:34:26 - De-queuing 7570 - mp3 - /mnt/hd2/My Video/[MP3]/20211004.ts
1487    14/04/2022 10:34:26 -     OK - 154.95 MiB in 23.288 seconds - 6.65 MiB/s -
1486    14/04/2022 10:34:25 - decrypt:  Removing/binning old copy.
1485    14/04/2022 10:34:03 - decrypt:  DLNA: http://127.0.0.1:9000/web/media/1238.TS
1484    14/04/2022 10:34:03 - decrypt:  DECRYPT: /mnt/hd2/My Video/[MP3]/20211004
1483    14/04/2022 10:34:02 - De-queuing 7569 - decrypt - /mnt/hd2/My Video/[MP3]/20211004.ts
1482    14/04/2022 10:33:15 -   /media/My Video/[MP3]/20211004 - Queued for mp3.
1481    14/04/2022 10:33:11 -   /media/My Video/[MP3]/20211004.ts - Queued for decryption.
1480    14/04/2022 10:33:05 - Renaming /media/My Video/[MP3]/########.ts to 20211004

Note line 1480 (which was a sweeper action), in contrast to lines 1490, 1489, 1486 etc.

 

[MymsMan]

They're produced by the WebIf framework, rather than Sweeper itself. I doubt you'd want all the plugins logging start/stop constantly at debug level 0.

In that case probably level 1 - 'scan information' would be more appropriate

 

[prpr]

Both of those are in the same area of code. Think I have made it work. Will roll a new WebIf beta later.

 

[prpr]

Try beta WebIf 1.4.9-9.

 

[prpr]

Did this fix either, both, or neither?

 

[MymsMan]

Did this fix either, both, or neither?

Not sure which 'both' you are referring to
If it is the start and end log records at level 1, yes to both (which I tried to indicate by liking the previous post)

 

[prpr]

I meant BH's comment in #28, and yours in #29 (which you've now answered), both referred to in #30. The like was a bit too subtle on this occasion.

 

[Black Hole]

Now I have access to some data...

Log lines are being announced as "autotrigger" rather than "sweeper" (or whatever module is performing the action).

 

[MymsMan]

I meant BH's comment in #28, and yours in #29 (which you've now answered), both referred to in #30. The like was a bit too subtle on this occasion.

The identification of actions is working for me for both standard auto

709    17/04/2022 22:07:05 - flatview:FV: +++ Adding Gentleman Jack_20220417_2100
708    17/04/2022 22:07:02 - sweeper:Queued /media/My Video/ [FlatView]/Gentleman Jack_20220417_2100.ts for thumb -offset 7
707    17/04/2022 22:06:53 - sweeper:Deleting /media/My Video/BBC News/BBC News_20220416_2159.ts

and autotrigger

649    17/04/2022 19:00:54 - decrypt:autotrigger[31707]:   /media/My Video/Michael Ball_ Showtime_20220417_1759.ts - Queued for decryption.
648    17/04/2022 19:00:32 - sweeper:autotrigger[31707]: Renaming /media/My Video/One and Six Zeros/New_ One and Six Zeros_20220417_1801.ts to One and Six Zeros_20220417_1801
647    17/04/2022 19:00:32 - sweeper:autotrigger[31707]: Setting title for /media/My Video/One and Six Zeros/New_ One and Six Zeros_20220417_1801.ts to One and Six Zeros

The autotrigger prefix already existed prior to the recent changes

 

[Black Hole]

Ah, it would help if I installed the beta update! (Another machine is set to install automatically)

 

[Black Hole]

Yep, getting the same as MymsMan.