View Single Post
  #25  
Old 13.09.2021, 18:56
pspzockerscene's Avatar
pspzockerscene pspzockerscene is offline
Community Manager
 
Join Date: Mar 2009
Location: Deutschland
Posts: 71,140
Default

Quote:
Originally Posted by EquiNox View Post
I see, had not paid attention to it before but it looks like you need to be logged in at Flickr to see the /archives/date-taken/ view.
Doesn't matter.
JD will find that property even without flickr account.

Quote:
Originally Posted by EquiNox View Post
What I wanted to say is that Flickr does not always use the same usernames for their different views. It's a bit confusing I'd say.
Doesn't matter either.
The fact is that there seem to be 4 usernames in total.
As long as they're all consistently/correctly found- and set via plugin it does not matter which one us used by flickr at which place as you can use whichever you want inside JDs filenames.

Quote:
Originally Posted by EquiNox View Post
First of all this was indeed a big quality update for the Flickr-plugin with so many new options but also improvements under the surface! Thank you very much pspzockerscene!
You're welcome.

Quote:
Originally Posted by EquiNox View Post
The biggest improvement imo, pictures downloaded with JD now should always contain the EXIF-tag when they were uploaded that way at the Flickr page. In the past I wasn't sure why maybe 10% of all pictures downloaded from Flickr were missing the EXIF-tag, although Flickr showed the date taken on their page. Before I thought this was an issue with Flickr but after now all these pictures obviously can be fixed afterwards with a re-download I am almost certain it was an issue with JD. The EXIF-tag is very useful especially for using the original-date-taken stored there by the camera, for chronologically sorting pictures with tools like EXIFtool for example.
It was not a JD issue.
JD cannot(yet) write EXIF data.
All data it downloads is downloaded as it is served via the server (in this case via the flickr.com CDN) so there must have been a serverside change...or the place our plugin is getting the downloadlinks from is different and leads to the pictures with EXIF data although I've always only been able to find one unique downloadurl per image-quality.
Mabe EXIF data is only available for images which can be officially downloaded (quality == "ORIGINAL" (/o/))?

Quote:
Originally Posted by EquiNox View Post
1. First of all the biggest flaw I found, that videos in Flickr-streams will never be downloaded when you parse the stream.
Fixed.

Quote:
Originally Posted by EquiNox View Post
2. There is another issue with some videos which however more seems to be a Flickr issue and which did not just occur with the new updates. It applies mostly to videos 360p or smaller, but some bigger ones as well.
Fixed.

Quote:
Originally Posted by EquiNox View Post
However when you play the video it's possible to save it manually via right click on the video. Would it be possible to get JD also downloading these?
Yes.

Quote:
Originally Posted by EquiNox View Post
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 EquiNox View Post
3. The username tags already work very well. However there is one change that I'd appreciate since I think the Flickr plugin worked already before that way and it would make updating streams much easier as I would not constantly have to toggle between *username* and *username_internal* for the custom filename. I think we would have a better backward compatibility to the old *username* tag, that was used for many years already.
Please keep in mind that the URLs you add may either contain the value of "username_internal" or "username".
To add the ability to use this inconsistent website behavior in JD too, I've added a new tag "username_url" that will return the username used inside the URL.

Quote:
Originally Posted by EquiNox View Post
4. There was another issue with single link parsing that I have seen, unicode characters in file names are replaced by cryptic codes.
I'll check this soon.

Quote:
Originally Posted by EquiNox View Post
That would of course make more things much easier, although it's already very powerful plugin especially with the latest updates. Thanks again!
As mentioned above, at this moment I've yet to find a reason to use flickr accounts in JD.
If there is one, simply removing account support might also be an option

For all code changes mentioned in this post, the following applies:

Wartest du auf einen angekündigten Bugfix oder ein neues Feature?
Updates werden nicht immer sofort bereitgestellt!
Bitte lies unser Update FAQ! | Please read our Update FAQ!

---
Are you waiting for recently announced changes to get released?
Updates to not necessarily get released immediately!
Bitte lies unser Update FAQ! | Please read our Update FAQ!


-psp-
__________________
JD Supporter, Plugin Dev. & Community Manager

Erste Schritte & Tutorials || JDownloader 2 Setup Download
Spoiler:

A users' JD crashes and the first thing to ask is:
Quote:
Originally Posted by Jiaz View Post
Do you have Nero installed?
Reply With Quote