Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Tiny Irritation With RSSfeed Scanner Plug-in
#1
I recently upgraded to v. 1.5.1 of the RSSfeed Scanner plug-in in Vuze v5.7.3. I think the version I was using before was v1.4.2.

I really like "tags" and have set up my filters so that my regular series downloads are tagged and appear in the appropriately named tag tab.

But what I have noticed is that whenever I return to the RSSfeed Scanner tab, it now always starts with the Status tab displayed, within the RSSfeed Scanner tab. I usually want to see the Options tab and I always set up the columns in the "Filters:" section of the Options tab so that the "Mode" and "Type" columns are as narrow as possible, and the "Name" column is as wide as possible, because it is the "Name" column that I usually need to see.

I achieve this by double-clicking on the dividers between the titles of the columns. I start with the divider to the right of the Mode column. By double clicking, that column becomes as narrow as possible.

Then I double click on the divider between Mode and Type - this makes the Type column as narrow as possible.

Finally I double-click on the divider between Type and Name - this makes the Name column as narrow as possible. Actually, it makes the Name column use all of the remaining width because the names are all the same length.

If you look at "before.jpg" attached, you will see columns as they initially appear - the Name column has a lot of text truncated, and the Type and Mode columns are unnecessarily wide.

Now look at the "after.jpg". The Name column is much wider and shows all the detail I need it to show because the other two columns are much narrower. So this is what all my "double-clicking" achieves.

Now the problem: in the latest version of the RSSfeed Scanner, whenever I return to the RSSfeed Scanner tab from another tab, it always starts with the Status tab displayed. Then when I click on "Options", all the columns are reset to the original widths as in my "before.jpg". So all the work I did setting the up the column widths has been lost.

This did not happen with the previous version - v1.4.2 - that I used. I would also guess, judging by the amount of time Vuze takes before it displays the contents of the RSSfeed Scanner's "Status" tab, that there is a lot of resetting/checking going on with this version.

My request is this: is it possible for the current column widths that the user has configured in the Options tab to be left unchanged, i.e. not reset, when the RSSfeed Scanner tab is returned to from another tab.


Sorry for the long post, but I think too much information is better than not enough.

Cheers,

Roger.


Attached Files Thumbnail(s)
       
Reply
#2
Try version 1.5.2 :)
Reply
#3
(01-19-2017, 03:44 PM)'parg' Wrote: Try version 1.5.2 :)





 

What can I say? Simply "brilliant".

Thank you so much.

Edit, 20/1/2017:

Sorry to say here follows another long post because all is not well with the plug-in.

First of all, functionally it works perfectly. But tonight I noticed my CPU was running always at 25+% for Azureus  (I always have SysInternals' "Process Explorer" running and showing in my System Tray) and my CPU was running hot: 60 - 65C (SpeedFan 4.5.2 and Speccy 1.29.714).

So I uninstalled the RSSfeed Scanner plug-in and the temperature returned to normal and Azureus.exe was using minimal CPU.

To make sure it was the plug-in causing this high CPU and temperature, I reinstalled it but initially there was no problem because the "rssfeed.options" file was the initial empty one - there were no source URLs and no filters. So I restarted Vuze after copying back my latest safe copy of "rssfeed.options" to the Applications Data folder and, when restarted, all the feed URLs returned, all the filters were present but the CPU was high and the temperature was high.

I repeated the above with RSSfeed Scanner v1.5.1. The high CPU and temperature occurred in exactly the same way. Again, when the "rssfeed.options" file is initially empty, there is no problem. As soon as there is "work" to do (when my normal file is copied back)), the CPU gets busy and hot.

But - and I hope this is useful to you - when I repeated the above with version 1.4.2 of the RSSfeed Scanner plug-in, there was no high CPU and, consequently, no high temperature. This was after I'd copied back the rssfeed.options file so I had all the usual feed URLs defined and the filters were all working.

So I hope you can track down where all the CPU is going in the latest RSSfeed Scanner plug-in. It feels like a bit of code that is just going round in circles and never completing (ex-software engineer talking here :)).  If you need help, I'm happy to try different versions of the plug-in until I find the one where the CPU gets busy, that is if you can't find it, but I would expect you to have all sorts of "performance analysis" tools at your disposal. Anyway, the offer is there and I hope you can get to the bottom of this.

My CPU is a 4 core i5, so it's not too slow. I'm surprised others haven't noticed the high CPU usage and/or temperature. Maybe my RSSfeed filter options are more complicated than most peoples'. I use a lot of RegEx and I'm sure that puts a load on the program.

Best regards,

Roger

Edit #2:

My rssfeed.options file is 6,413,744 bytes in size. Is this normal?
Reply
#4
Hmm! I don't use rssfeed myself so not sure what a typical config file size would be :( Unfortunately the author decided to use Java serialization to store his configuration objects so what is going on is hard to see by examining the file. Can you check the Vuze 'logs' folder for files names thread_1.log and thread_2.log - these contain snapshots of CPU usage and if a particular thread is taking significant CPU it is identified there - see if you can make any sense of them and post them here if you want.
thanks!
Reply
#5
(01-23-2017, 11:10 AM)'parg' Wrote: Hmm! I don't use rssfeed myself so not sure what a typical config file size would be :( Unfortunately the author decided to use Java serialization to store his configuration objects so what is going on is hard to see by examining the file. Can you check the Vuze 'logs' folder for files names thread_1.log and thread_2.log - these contain snapshots of CPU usage and if a particular thread is taking significant CPU it is identified there - see if you can make any sense of them and post them here if you want.
 thanks!

 
OK, I'll have a look tomorrow and report back as I'm on a different PC at the moment.
Reply
#6
(01-23-2017, 11:10 AM)'parg' Wrote: Hmm! I don't use rssfeed myself so not sure what a typical config file size would be :( Unfortunately the author decided to use Java serialization to store his configuration objects so what is going on is hard to see by examining the file. Can you check the Vuze 'logs' folder for files names thread_1.log and thread_2.log - these contain snapshots of CPU usage and if a particular thread is taking significant CPU it is identified there - see if you can make any sense of them and post them here if you want.
thanks!



 

I agree about the rssfeed.options file - very difficult to understand. It appears to have huge snippets of web pages in it (IMDB type of story decriptions of the program being downloaded), and has some really old .torrent web site information - torrent sites that I haven't used for years and that are no longer in the options.

I'm tempted to delete all the options and re-enter them to see if I can clean up the file, but that would take a while and I would need to write macros to extract all the info first and then re-enter it.

Regarding the CPU usage, I've opened Tools/Options/Logging, enabled logging and enabled logging to a file in a folder on my SSD, and Saved the settings. Now waiting for something to be produced - no files after 5 minutes. Do I need to do something else to trigger the creation of these log files?

Edit, several hours later...

Looks like the "Tools/Options/Logging/Log file directory" is ignored by Vuze, as the logs have appeared in my "Profile\Application Data\Azureus\logs" folder.

Later, I will update the RSSfeed Scanner plug-in and see if the high CPU usage is captured in the log files.
Reply
#7
There's two kinds of logging - the very detailed log of activity that has its save location set in the config (along with enable/disable) and the other set of area-specific log files that reside in the 'Azureus\logs' folder. The detailed log file doesn't contain thread CPU usage information, for that you need to look at the Azureus\logs\thread_1.log (and _2.log) files
Reply
#8
(01-27-2017, 08:48 AM)'parg' Wrote: There's two kinds of logging - the very detailed log of activity that has its save location set in the config (along with enable/disable) and the other set of area-specific log files that reside in the 'Azureus\logs' folder. The detailed log file doesn't contain thread CPU usage information, for that you need to look at the Azureus\logs\thread_1.log (and _2.log) files





 

Hi parg,

Vuze has been running each day since I last posted but the only "thread_1.log" and "thread_2.log" files on my computer were from 2008 and were located in a personal folder, i.e. not a "program files" or "application data" type of folder. Besides, the date indicates that they are very old files.

The first few lines in "thread_1.log" (257 KB) are:

[2008] Log File Opened for Azureus 3.0.3.4

[1201 23:28:20] Monitoring starts (processors =1)
[1201 23:28:30] Thread state: elapsed=10000,cpu=0,max=VivaldiV2PositionProvider:ping[1](0/0%),mem:max=130112,tot=6568,free=2019
[1201 23:28:40] Thread state: elapsed=10000,cpu=6250,max=main(5922/59%),mem:max=130112,tot=6876,free=2170


The first 3 lines in "thread_2.log" (2 KB) are:
[1601 14:05:53] Thread state: elapsed=10016,cpu=63,max=PRUDPPacketReciever:16881(31/0%),mem:max=130112,tot=14700,free=6170
[1601 14:06:03] Thread state: elapsed=10000,cpu=139,max=PRUDPPacketReciever:16881(78/0%),mem:max=130112,tot=14700,free=6252
[1601 14:06:13] Thread state: elapsed=10000,cpu=94,max=ReadController:ReadProcessor(32/0%),mem:max=130112,tot=14700,free=6550

I did enable logging in "Tools/Options/Logging", but that produced "az.log" and "az.bak" which don't contain the CPU information that is in my old "thread_n.log" files.

So can you give me exact instructions on how to turn on logging to get these files produced?

When I am able to produce these log files, I will update the RSSfeed Scanner plug-in to the latest version and try to find where all the CPU usage is going.


Thanks,

Roger
Reply
#9
If you go to Tools->Options->Plugins there are 'links' at the top of the panel to 'shared plugins' and 'per-user plugins'. If you open the per-user plugins folder then the logs should be stored in the 'logs' folder that is in the *parent* folder of the plugins one,
Reply
#10
(01-27-2017, 12:59 PM)'parg' Wrote: If you go to Tools->Options->Plugins there are 'links' at the top of the panel to 'shared plugins' and 'per-user plugins'. If you open the per-user plugins folder then the logs should be stored in the 'logs' folder that is in the *parent* folder of the plugins one,

 

Hi parg,

Thanks for the clarification!  I found both the thread_1 and thread_2  .log files in that folder.
I'll let Vuze run for a while with version 1.4.2 of the RSSfeed Plugin and then copy the log files.
Then I'll install version 1.5.1 - the version that appeared to use a lot of CPU and cause the temperature to rise - and copy those files also.

Then I'll try to decipher what the logs say and report back.

Thanks again.

Roger
Reply
#11
excellent!
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  RSSfeed Scanner - Age column Linuxxx 0 720 03-29-2017, 06:40 AM
Last Post: Linuxxx
  RSSfeed Scanner Plug-in stopped working Havokdan 0 960 01-27-2017, 08:53 AM
Last Post: Havokdan



Users browsing this thread: 1 Guest(s)