Quote:
Originally Posted by pspzockerscene
If in the end you are sure it is a flickr bug, you may report that to their staff although it's nothing major.
Some applications using pagination may stop if a page contains less than max items so that's the worst that this bug can do.
|
Reconsidering, this could also be the explanation for those discrepancies I was talking about, number of items stated on the user front page and number of items JD is getting in the end. I had not seen this before but now it obviously makes sense. We talked about it before...
Quote:
Originally Posted by pspzockerscene
Quote:
Originally Posted by EquiNox
I saw that already works very well. I did notice myself there can always be a certain discrepancy between the amount of pictures stated on the user front page at Flickr and the amount that actually shows up in the stream in the end. And I am not talking about any mature content that is not visible for JD since it does not yet have a working Flickr account support. In most these cases there is however only a difference of a few pictures. In this case I use the /archives/date-taken/ view to crosscheck because in most cases that shows the correct number of items in a stream.
|
Do you have example URLs for that?
As said I'll do some more tests but afaik the problem is not the mature content (anymore).
Also, are there URLs which require login but are not mature?
E.g. private photos of other users which are only unlocked for you or other specified users/friends?
If so, I'd need to get some examples to work on/check login support. |
Quote:
Originally Posted by pspzockerscene
Next update:
flickr video support:
- Added "preferred quality" selection along with correctly filling "quality" tag
- Enabled faster linkcheck for videos too
- Allow resume and chunkload for videos
I purposely left out "240p" which is listed internally as "700" and is pretty much the only available quality for old videos.
Same as for pictures:
If the selected quality is not found, the "best" will be used instead.
For videos added before this update, the quality tag may just return "original".
This is auto-corrected when adding them again.
Also, last update updated filename patterns for all users who were still using the default.
New default is:
Code:
*username_url*_*content_id*_*title**extension*
...which basically creates exactly the same filenames used before I started to work on these huge changes on the flickr plugin.
|
Looking forward to this new update!
One difference to the old Flickr plugin before the big update I noticed when downloading. When I want to stop downloads and resume them later, I am asked "Do you want to stop all running downloads? You would lose x MB due to y non resumable Downloads?" Did this change come with the new implementation? If I am not mistaken it was not like that before. Not a big issue but generating some unnecessary traffic.