Error in JS Webpage

[treyg]

Error in JS Webpage

[grandmastermarco]

I just figured out using port 5001 fixed the Problem. Now it works like a charm.
Maybe add this to the documentation?

[grandmastermarco]

I just found out that the links generated with https and no certificate set don't open in all browsers, and if so, only with the standard error message of untrusted certificate.

To summarize:
Environment: Synology NAS in local network only - no certificate - no https

Right now: Docker env has to be set to NAS:5001 (iso 5000)
When opening the webpage (no problem so far) all pictures appear blanked out.
When following a link and accepting the unsecure state without certificate, all pictures show correctly afterwards.

Suggestion:
Provide another ENV variable with https true/false state.
If false: use port 5000, if true: use port 5001.

Thank you very much once again for this project ;)

[marvin78]

Works fine. Thank you again

[grandmastermarco]

The only difference to the setup guide is i put the local NAS IP plus Port instead of quickconnect adress, as i dont use quickconnect.

My NAS IP inserted as follows: 192.168.0.2:5000 (no https)

[Loenus]

Hi @grandmastermarco , thank you for all the feedbacks!

Can you try to set NAS_IP without port? I have the same environment as yours and it works for me. Specify the port is not required since you set “photo” alias.

About the other problem, I don't know how to solve it. If you don’t have a ssl or quickconnect, then the first time you open the webpage on any browser, you have to follow a link and ‘accept the risk’. The only thing I can think of is to specify this 'action to do' in the README, so that it seems like expected behavior.

Anyway can you elaborate in which browser the webpage fails to open?

[grandmastermarco]

About the other problem, I don't know how to solve it. If you don’t have a ssl or quickconnect, then the first time you open the webpage on any browser, you have to follow a link and ‘accept the risk’. The only thing I can think of is to specify this 'action to do' in the README, so that it seems like expected behavior.

This is exactly the issue. I am using Chrome / chromium right now, but I am 99% Sure this will be an issue on all Browsers.

I will not use quickconnect for safety reasons (using a vpn for outside access).

Would it be a lot of coding work to implement the suggested SSL / HTTPS environment variable?

Thanks for feedback!

[grandmastermarco]

Just for reference what I see before 'accepting' the risk of an unsecured connection...

After clicking on any picture, and accepting the unsecure webpage, everything works fine..

[marvin78]

I have the same error. But I cannot fix it by setting IP with 5001. Even Quickconnect URL does not work.

I checked the API URLs. They do work. What could be the problem here?

[treyg]

@marvin78 So you have quickconnect enabled on your nas? Can you share a screenshot of your settings in container manager? (hiding any sensitive info)

[marvin78]

Quickconnect is enabled. But do not want to use it. I used it for testing here. I really want to use local IP

One other thing. Would it be possible to have a setting to choose between "Foto" and "FotoTeam"?

[marvin78]

So I changed network to host, changed the port and to FotoTeam in index.js and it works so far. The interesting fact is, that firewall cannot be the reason why it does not work in bridge mode. Even if I switch it of, it does not work. wget out of the console of the container cannot connect to the NAS-IP in bridge mode either.

But no fotos are found (I take at least one foto every day). Not in month, day or week mode. I debugged it a little bit and I can see that the json return has fotos in it but after filtering for day, week or month there is nothing left. Any idea?

Edit: I changed the following function and get a result (all photos):

function filterPhotosByDay(photos, day, month) {
  const currentYear = new Date().getFullYear()
  return photos
  //return photos.filter(photo => {
    //const takenDate = new Date(photo.time * 1000)
    //return (
     // takenDate.getDate() === day &&
      //takenDate.getMonth() + 1 === month &&
      //takenDate.getFullYear() < currentYear
    //)
  //})
}

I thinkt the filter(s) could be wrong.

Second edit: I think it's a problem with the pure count of fotos. The fotos in stock are too old because the api does not return all of them. I think there should be a filter in the original request:

https://${ip}/photo/webapi/entry.cgi?api=SYNO.FotoTeam.Browse.Item&version=1&method=list&type=photo&offset=0&limit=5000&_sid="${sid}"&additional=["thumbnail","resolution"]

The limit is 5000. But it does not get the newest fotos in this limit.

[treyg]

@marvin78 Interesting. I'll look into this tonight if I get some time. Is the email working properly if you click on the individual photo urls?

[marvin78]

I know what the problem is. I debugged it a lot. The problem is: The limit is 5000. I have much more Fotos in one year than 5000. So I never can get fotos from a year ago (and this is meant with memories or am I wrong there?). If I try to get more than 5000, I get errors from the API. So I think the real limit in the API is 5000.

What I don't know is: Can we pre-filter in the API-request? Something like [...]&from_date=[year-1]-m-d&to_date=
[year-1]-[m+1]-d[...]

What photo URLs? I do not get fotos. The log says: "No photos to send."

[treyg]

@marvin78 That makes sense! Thanks for bringing that up. I only have about 2k photos total, so I wasn't sure what would happen with more than 5k.

I created a new branch with pagination added to the request, so it should work. Though I'm not entirely sure how it'll handle with a huge number. If you get some time, will you try pulling 0.2.5 from docker hub and see if that works? This is the version with the updated code.

[marvin78]

Thanks. If I alter the code and set Foto to FotoTeam than it works with this branch. It would be nice if that could be done over ENV or settings.

This tool is great. One thing would be nice for the future: If it is possible (I did not look that far) to build Shared Albums over the API than this tool could build this Album with the selected fotos (name it October 2022 or Week 40 2022 or something like that and share it with users, set in the ENV or settings) to send and only send the link to this album. Than one would not need to click every single foto. :)

EDIT: Alternative always could be to send the link to the webpage of this tool
2nd Edit: You already do that. Too much fotos on my side. I don't see the end. Maybe putting it to the beginning of the mail would be good.

[treyg]

@marvin78 Great! Glad it's working now. I'll get that pushed to the latest image. Are you saying you're having to go into index.js and change Foto to Fototeam in the request URL here?

  const photosResponse = await fetch(
       `https://${ip}/photo/webapi/entry.cgi?api=SYNO.Foto.Browse.Item&version=1&method=list&type=photo&offset=${offset}&limit=${limit}&_sid=${sid}&additional=["thumbnail","resolution"]`
     );

I'm guessing that would just be because of what space your photos are in, but that shouldn't be hard to make optional in the settings. If that's the case, are you also changing it in the thumbnail request? I'm assuming not since it for the individual thumbnail - just want to make sure.

function getThumbnailUrl(ip, sid, photo) {
  const {
    id,
    additional: {
      thumbnail: { cache_key }
    }
  } = photo
  return `https://${ip}/photo/webapi/entry.cgi?api=SYNO.Foto.Thumbnail&version=1&method=get&mode=download&id=${id == cache_key.split('_')[0] ? id : cache_key.split('_')[0]}&type=unit&size=xl&cache_key=${cache_key}&_sid=${sid}`
}

[marvin78]

I changed It everywhere. I do not have fotos jn personal space.

[treyg]

@marvin78 I just pushed an update to the latest flag with an env option for FOTO_TEAM. You should just be able to set it to true and have it work as expected without having to change any code. Let me know if you have any issues!

[marvin78]

I will try that at the earliest time possible. Thank you.