Recent Posts by David M
|
Oct 26, 2007
|
If I am correctly interpreting what you mean by a “green check mark”, then under Complete it means that you won the item, while under Current it means that you are currently the highest bidder. David |
|
Aug 17, 2007
|
This would be a very useful feature, but I can see obvious problems. The usefulness arises for people who regularly have to search for, and bid on, items from multiple countries. For example, if something is not readily available in my home country, Sweden, then I will buy from somewhere else in the European Union (in either pounds or euros) or from the USA (in dollars). If I am bidding on multiple items, then I end up using a spreadsheet to compare the items in some standard currency (which, believe it or not, in my case is Australian dollars, since that is the currency I will be paying in). I then have to work out what to bid for each item in its original currency, minus shipping costs. JBidWatcher allows me to automatically take into account the shipping cost, but not any other part of the procedure. The obvious problem is getting JBidWatcher to do the currency conversions. Even eBay uses only “approximate” currency equivalences, standardising on the currency used by the site from which the items are being accessed. Is there really a way to get JBidWatcher to do currency conversion in a manner that the user could always rely on? Can eBay’s equivalences be accessed? Or are we opening up a can of worms that the program is better off leaving closed? The currency conversion that ultimately matters is the one used when paying, of course, not the one used when bidding. So, I guess that any solution is just an approximation (as is the one used in my spreadsheet, which is an average of recent currency movements). David |
|
Aug 17, 2007
|
I find that the simplest way of doing complex searches in JBidWatcher is to use the URL Load option rather than using a search string. This is explained in the FAQ accessible from within the program itself. Basically, you use eBay’s own Advanced Search page to refine your search options, until eBay displays only the items you want, and then you load the resulting eBay URL into JBidWatcher. Like yourself, I need specific options such as country availability (Sweden fought off this piece of Americana, so that www.ebay.se was eventually closed down, and eBay then literally purchased their local competitor, tradera.se), and also PayPal availablity (I am always an “international customer”, no matter who I buy from, and PayPal is thus essential), as well as often new/used. I find that the URL Load approach is the most effective way to get this type of refined search into JBidWatcher. By the way, JBidWatcher does use the ebay.com site as its standard for everything, thus hopefully by-passing all localisation issues. This should work because all eBay items are supposed to be available via all eBay sites. However, you can perform your Advanced Options search from another eBay site, and then load the resulting URL into JBidWatcher. David |
|
Aug 17, 2007
|
I am getting the same problem at ebay.co.uk JBidWatcher cannot currently load any item pages from the server. David |
|
Aug 12, 2007
|
Under the File menu there is an item called “Clear deleted tracking”. Try doing that after you have deleted the unwanted auctions. When deleting, JBidWatcher merely hides the auctions but still keeps track of them, so you need to “delete” everything twice. David |
|
Aug 3, 2007
|
My recent experience with eBay may be relevant here. A few days ago eBay started insisting that I must enter a credit card number in order to “confirm” my identity. I was not allowed either to bid or to send messages to other eBay members until I did so. Previously, I could do both of these things unhindered, without having registered a card number with eBay. Whenever I tried to do either of these two actions, I was re-directed to the login page (even though I was already logged in at the time), and then from there to the page for entering a credit card number. Entering a card number solved the “problem” (although I am not happy about the number being stored by eBay, since I will not be using it – I use PayPal). So, anyone having JBidwatcher problems might like to try some manual actions, to see if eBay is doing similar things to them. If they have never given eBay a card number then this may explain the sniping failures. David |
|
Jul 28, 2007
|
The current version of JBidwatcher seems to have problems parsing pages in which a BIN item has been won with a Best Offer, instead. As an example, Item 180087104618 was won (by me) with a Best Offer of US$6.00, as displayed in the relevant part of the eBay page. However, when this item was first won (ie. when the item was moved from the “current” to the “complete” tab), my copy of JBidwatcher displayed the Current price as:
unk1.49 Has anyone else come across this issue? David |
|
Jul 28, 2007
|
What you appear to need here is to access the context-sensitive menus for the different sheets, or tabs (as JBidwatcher calls them). There are actually several such menus in JBidwatcher, which you access with a ctrl-click on different places. So, if you ctrl-click on any of the “current”, “complete” or “seller” buttons you will bring up a menu that allows you to modify the respective tab, including adding and deleting columns separately for each tab. I don’ think that you can change the order of the columns, however (or, if so, then I have no idea how to do it). David |
|
Jul 25, 2007
|
I am not sure that this is a bug. “Snipe” is simply the first item in the contextual menu, and this is therefore highlighted by default (another item may be chosen depending on how close the menu is to the edge of the screen). Whether the highlighted item is executed immediately depends on your mouse settings. On my OSX 10.3 system, ctrl-clicking simply brings up the contextual menu and then waits for me to explicitly choose one of the menu items. David |
|
Jul 25, 2007
|
I, unfortunately, also came across the can’t-save/can’t-quit problem, just before 1.0.2pre5 was released. This new release does, indeed, seem to solve the problem on OSX10.3 – I could re-load the offending items (which got lost during the previous OSX force-quit), and then I could quit JBidwatcher normally. By the way, on my machine the http link to the Source Code for these pre-releases simply gives the following message: “The files in the beta directory were not really intended for long-term and widespread distribution.” The links to the apps work normally, however. Also, I noted an earlier post concerning Shipping costs not being loaded. I find that this occurs about one-quarter of the time for me, even when the costs are clearly indicated on the eBay item page. I haven’t noticed any obvious pattern as to which items are concerned, and the costs are easy to add manually via the context menu. Is this likely to be a problem with parsing particular eBay pages? Some example, items are: 300124590816, 280136089897. (NB. I have to change the Shipping costs from the default location to “Sweden”.) David |
|
Jul 23, 2007
|
It seems unlikely that this issue is related to the other recent problems caused by eBay formatting changes, so I am posting this as new topic. I recently had the following experience: I have not had JBidwatcher mis-calculate bid increments before. Is this a recent problem? David |
|
Jul 23, 2007
|
I can confirm the reports from other users that the red-eyes sporadically come and go for me, also, using 1.0.2pre4 under OSX10.3. There seems to be no pattern as to which auctions will show the red-eye during which automatic updates, and they all go away immediately when each offending auction is manually updated. The console log shows that this pair of messages is the most common cause: However, this type of message also appears on occasion (but so far not twice for the same auction): David |
|
Jul 21, 2007
|
I can confirm that the compiled JBidWatcher-1.0.2pre2 works fine on my Mac with Java 1.4.2 (unlike the previous Java 1.5 version, which wouldn’t work at all). However, Shop items do still start with “29 d, 23 h” and then swap to “N/A”. I am also still getting discrepancies between JBidWatcher and eBay with regard to Vehicles, but oddly enough it seems to be eBay that sometimes produces the wrong numbers. I have just checked a number of cars, and JBidWatcher has the correct end time based on the “List Date” and “Duration” information in each of the item pages. However, the “Time Left” information shown on the eBay Search page can be anything up to 5-6 minutes different, irrespective of how often I refresh that page (and the discrepancy varies between refreshes). This may also explain item 260130815829, which I chose originally because eBay listed it as finishing in a few minutes time. Perhaps it was updated to a “Duration” of 60 days in the minute between when the item page was displayed for me and when JBidWatcher read the information. I don’t know if anyone else can reproduce my results, but JBidWatcher may now be a more reliable source of time information than some of the eBay pages! Perhaps their formatting changes have not been an improvement for their customers. David |
|
Jul 20, 2007
|
In the current CVS version, there appear to still be some time issues with BIN sales from Shops, etc. For example, if I quit JBidWatcher and then restart it, any saved Shop items (with no time information) first come up with a very large single number in the “Time Left” field. They are then changed to “N/A” during the first update of the auctions. Also, it is possible to get apparently contradictory information from eBay and JBidWatcher. For instance, if I do a search, then the search results page for any Shops items DO show a specific “Time Left” value for each item. However, this “End time” information is not displayed on the individual item pages themselves, and so JBidWatcher will not find it. Instead, JBidWatcher first displays “29 d, 23 h” in its “Time Left” field when any such item is transferred, which it later changes to “N/A” during the first update. Vehicles seem to have a time issue. For example, item 260130815829 is a Classified Ad listed on its eBay page as a “30-day listing” from “21-Jun-07”, and yet JBidWatcher lists the “Time Left” as “29 d, 23 h” from when it is first transferred (in my case, with the listing apparently ending on “Mon Aug 20 00:43:45”). On the other hand, Vehicles with a specified BIN “End time” on the item page (eg. 320138801845) are transferred to JBidWatcher correctly. David |
|
Jul 20, 2007
|
I have successfully compiled the recent CVS update under Java 1.4.2 for Mac OSX 10.3, and I can confirm that all of my previous eBay problems have been addressed. Thanks Morgan. I will, however, see if I can dig up some replacement problems for you (eBay is bound to have done something else unexpected). By the way, lots of Mac users are still stuck with Java 1.4.2, since 1.5 is not officially supported for OSX 10.3. (A number of people have found that 1.5 will work on 10.3, anyway, but others have encountered graphics problems.) I therefore hope that the final version of JBidWatcher will not rely on 1.5 (or 1.6), and I am happy to continue to compile and test things under 1.4.2. David |
|
Jul 20, 2007
|
As a follow-up to my earlier post, I have now come across two current BIN sales (250112869109, 200118062378) that, on my computer, are listed by JBidWatcher (1.0.2pre1, compiled using Java 1.4.2-12 on OSX 10.3.9) as ending on 31-Jan-70. I have been watching these two sales for some time, and they have both recently had their expiry time extended. David |
|
Jul 20, 2007
|
I have compiled the most recent version from Morgan’s CVS and compiled it on Mac OSX 10.3.9 with Java 1.4.2-12. I can report that most things seem to work again except for those related to shops (ie. Registered as a business seller). For them, some sales show up in JBidWatcher as ending months in the future when they have in fact already ended (eg. 320138511858). Other sales cannot be loaded into JBidWatcher by either dragging or copying, irrespective of whether they are an auction (eg. 320138806939) or BIN (eg. 200118062378, 320139468352). Incidentally, I noticed when using Hans’ hack (which I also compiled) that similar problems existed (ie. although the sales would be updated they were sometimes updated with the wrong time). Perhaps other people should check whether their “updated” auctions are in fact correct. I think that not all of the format changes by eBay have yet been captured in the updates, as these changes seem to differ depending on the type of sale. David |
Topic: