It would be nice if JBidwatcher could be set to delete old auctions after a suitable interval as the db gets very full.

This the state of my machine for ages after I launch JBidwatcher due to too many auctions.

Tasks: 167 total, 2 running, 164 sleeping, 0 stopped, 1 zombie
%Cpu(s): 69.2 us, 1.9 sy, 0.0 ni, 28.2 id, 0.2 wa, 0.0 hi, 0.4 si, 0.0 st
KiB Mem: 3925848 total, 3686380 used, 239468 free, 142808 buffers
KiB Swap: 6160920 total, 816288 used, 5344632 free, 1102116 cached

26339 matthew 20 0 1799m 229m 21m S 99.7 6.0 3:24.98 /usr/bin/java -Xmx512m -jar /home/matthew/Downloads/JBidwatcher+
30005 matthew 20 0 1497m 359m 26m R 9.6 9.4 693:10.52 /usr/lib64/firefox/plugin-container /usr/lib64/browser-plugins/+
2884 matthew 20 0 2537m 855m 31m S 2.3 22.3 569:48.52 /usr/lib64/firefox/firefox
2867 matthew 20 0 531m 22m 13m S 1.7 0.6 7:34.58 kdeinit4: konsole [kdeinit] -session 101b31a21a516a00013997561
2374 root 20 0 286m 67m 20m S 1.3 1.8 183:37.65 /var/lib/X11/X :0 vt7 -nolisten tcp -auth /var/lib/kdm/AuthFile+
29775 matthew 20 0 1678m 247m 21m S 1.0 6.5 1:54.18 /usr/lib64/thunderbird/thunderbird-bin
26390 matthew 20 0 19376 1564 1052 R 0.7 0.0 0:00.74 top
534 root 20 0 72324 2292 1480 S 0.3 0.1 6:46.58 /usr/sbin/cupsd -f
2962 matthew 20 0 1136m 11m 6912 S 0.3 0.3 19:14.39 /usr/bin/turboprint-monitor 0 -hide
1 root 20 0 46064 4136 1444 S 0.0 0.1 0:02.18 /sbin/init

Yes, would be nice. But since it’s not a build in feature, so I opt to delete all my db and start with a fresh one as I had too many in db and it’s making launching the JBW slow

I started from scratch and just updated my ebay items, and it’s running smooth and fast …. and I now constantly delete all the old ones…… Whatever is past, is history…. besides, I can always find the same info in my email database… (if I ever need to look up an item I bought a year ago, or 9 months ago)…. that’s my way of making jBW still a lean trim machine and bid and win for me everyday.

Have fun with life guys…. Happy snipping now… :-D

Personally, back in time, I used to archive the .XML and do search in it. I do not use JBidwatcher anymore for sniping for multiple reason, mainly because it became unusable at some time and I probably lost lot of stuff and also I changed a little bit my habit at some point to avoid missing snipe. But my best combination was JBidwatcher + a backup (does not hurt with eBay as there is always something that happen).

Being a collector, I easily monitor and even bid on hundreds of items a week easily and with my computer (laptop, i3, 8GB ram [not super “small” even if for my usage pattern it is not enough, but I am the kind to have hundreds of windows and tabs opened in my browser, so maybe I am atypic]), once JBidwatcher’s item list get big, it just slow down the machine too much, often taking 100% of one CPU/Core, etc. Lot of things get inefficient like sorting, etc. I would say it is a “bad smell” for just a “list of items”… hundreds or thousands are not a lot in computer data. But I am sure there is reasons, good or bad. And it may not be the first design goal of JBidwatcher to be an “archiver”.

However, as an user, I would really like to archive everything I monitored and that since the first time I use JBidwatcher (years ago). Every snipes I took decision to put a price on (it can require considerable time to evaluate and decide on a price… if I could re-use my old data fast, that would save me a lot of time, like I said, I remember back then, I was scanning textually my XML backups to find out my old data). But then… we have a database… it should not be that hard to introduce a kind of “archive” mechanism (Morgan, if you read this, let me know what you think or if you have a clean/quick solution in mind, that will be really something useful). I way much prefer to archive than delete for the reason I said, etc.

Even if in short term it only mean that I put an archive flag to true and can’t access it, but it stays in the database, I would prefer this over having to delete each time to make it usable again.

Then later, we can have an option or a little interface to search archived items. But loading all in the current state of the software just make it almost unusable (at least on my machine).

I am actually thinking of writing my own tool. At the same time I gotta admit that JBidwatcher has been a very valuable tool in my bidding experience over the years, so that I write my own or not, if I can help with at least “simple and good idea” that improve it, I would be happy. Maybe if I am not lazy (read: if I am mad enough one day to just do it) I can also propose an implementation myself. ;-) We’ll see.

But fast, if I could only have a kind of “archive” option, that would be fantastic.

I do not know where the state of JBidwatcher is as I see you still post Morgan, but there is a lot of thing going wrong as I started back using it lately (I mostly use it as a monitor tool that can hold hundreds of items… eBay’s watch list that I tried, limit me to 200 items and that is far from enough for my needs). I am sure it is possible to do such tool without it needs to take 500MB+ of ram… I do not mind giving it more if it works fast… I think in the past I boosted its JVM memory to help, I would need to investigate that again…