View Single Post
 
Old 13.09.2021, 08:16
EquiNox EquiNox is offline
Wind Gust
 
Join Date: Sep 2021
Posts: 40
Default

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!

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.

A few issues however that could be improved I'd like to mention.

1. First of all the biggest flaw I found, that videos in Flickr-streams will never be downloaded when you parse the stream. You'll just get a jpg-preview of the video instead. However when you copy-paste the single link of the video, then the video file shows up in the LinkGrabber and can be downloaded correctly.

As an example you can use the Flickr page that you used yourself above.
Parse the stream and you don't get any video link in LinkGrabber, just the corresponding jpg-preview for the video:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

However there are 3 videos in this stream:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

Copy paste them singly and the videos show up in the LinkGrabber:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**

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.

Some random examples:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**

These show up in the LinkGrabber as 'offline'. Trying to download these directly from Flickr mostly returns this error message:

Code:
That 'size' is missing.
404
Unknown:
JSON | PHP | MsgPack
{
    "code": 404,
    "message": "That 'size' is missing."
}
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?


Quote:
Originally Posted by pspzockerscene View Post
- Fixed 99% of all missing images (mature content as part of sets/galleries/favorites); either flickr itself is boggy or there is still some work left
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.


Quote:
Originally Posted by pspzockerscene View Post
-psp-
EDIT

I'm actually a bit confused regarding the different "usernames".

Example:
flickr.com/photos/louobedlam/
API:
pathalias: louobedlam --> *username*
realname: Lou Noble --> *username_full*
ownername: Lou O' Bedlam --> *real_name*

Website:
pathAlias: louobedlam --> *username*
realname: Lou Noble --> *username_full*
username: Lou O' Bedlam --> *real_name*

I guess "username" and "username_internal" are correct but for the rest, website and API are using different fields.
Is the current handling fine or do I need to swap the data that goes into "username_full" and "real_name"?
I'am not a flickr user...
I am confused myself with all the different usernames at Flickr. For the plugin I think *username_full* and *real_name* already works fine. *username_full* the big headline on the top of the front page of the Flickr user and *real_name* the name stated below in the second row. I think we can leave it that way.

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.

The problem is that with the new update *username* does not always have a value anymore, only in case there is a pathalias available like you called it above. The change that I'd suggest is that in case there is no pathalias *username* would simply get the same value like *username_internal*. Maybe a simple way to implement this is just using the Flickr url to extract the value for *username*. Then you can decide yourself what username you want to use when you want to download from Flickr with JD. It just depends on what you copy-pasted, either the pathalias url or the internal username url.

To make it more clear taking your example from above:
Lou Noble - Lou O' Bedlam - louobedlam - 49229574@N00, you can open this site in two ways, either by using the pathalias or the internal username url. With the change that I suggest *username* would get different values when you copy paste a link for the LinkGrabber to parse:
Code:
https://flickr.com/photos/louobedlam/     ---> *username* = louobedlam
**External links are only visible to Support Staff**
This implementation would also easily fix the issue with *username* being empty in case there is no pathalias. Naming the tag *username_url* would probably make more sense in this case.

Example:
Irina Dimulescu - Irina1010 - no pathalias - 100184150@N02, there is only one way to open this Flickr site:
Code:
**External links are only visible to Support Staff**
I do not believe that this implementation would have any harmful interdependencies. Of course another way to implement this would be in case there is no pathalias to simply set *username* = *username_internal*, however this would not be as flexible as the suggestion above.


4. There was another issue with single link parsing that I have seen, unicode characters in file names are replaced by cryptic codes.

Example:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

Single link parsing returns this cryptic file name (custom filename: Flickr-*title*_*username*_*content_id**extension*):
Code:
Flickr-%u6417%u86CB%u6417%u86CB_anan5211_5067725471.jpg
The correct file name when parsing the stream:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
Code:
Flickr-搗蛋搗蛋_anan5211_5067725471.jpg
This unicode-bug seems to apply to any tag of the custom filename when parsing a single Flickr link.

Here is an example where *title* and *username_full* in the filename contain cryptic code:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

When you parse the album the link above is part of it's all fine again:
**External links are only visible to Support Staff****External links are only visible to Support Staff**


Quote:
Originally Posted by pspzockerscene View Post
Regarding flickr account support:
I'll work on this once all the other stuff is done.
@pspzockerscene:
That would of course make more things much easier, although it's already very powerful plugin especially with the latest updates. Thanks again!


I guess that's it for the moment when there are any other issues I will run across, I'll let you know.
Reply With Quote