2waltzmn
>1 bergs47: To get a bug fixed, you need to describe the actual bug.
What is the difficulty? Did you add something and it disappear? Can you not add information? Something else?
Which page did it occur on?
Can you cite an actual example (a book-and-movie pair), preferably with a link?
And while you're at it, you might as well cite your system details, which might matter. So:
Device (e.g. Dell PC, iPhone 18, Chromebook)
Operating system and version (e.g. MacOS 26, Android 18.3)
Whether you use a browser or the LT App
If a browser, which browser and version
So, for me, the information would be
Mac M1 laptop
MacOS Sequoia 15.7.4
FireFox 150.0.3
Any other details you can offer will help the developers.
Remember, the developers are not your enemy. The more help you give them, the easier for them to identify and fix the problem.
What is the difficulty? Did you add something and it disappear? Can you not add information? Something else?
Which page did it occur on?
Can you cite an actual example (a book-and-movie pair), preferably with a link?
And while you're at it, you might as well cite your system details, which might matter. So:
Device (e.g. Dell PC, iPhone 18, Chromebook)
Operating system and version (e.g. MacOS 26, Android 18.3)
Whether you use a browser or the LT App
If a browser, which browser and version
So, for me, the information would be
Mac M1 laptop
MacOS Sequoia 15.7.4
FireFox 150.0.3
Any other details you can offer will help the developers.
Remember, the developers are not your enemy. The more help you give them, the easier for them to identify and fix the problem.
3MarthaJeanne
And if they have no idea what the problem is, they will deal with other problems first. (As they should.)
4Nevov
In CK, on work pages, the Related Movies field, where it usually pulls data from IMDb when you're making an entry, isn't.
This is the topic from when it broke last time and was fixed: https://www.librarything.com/topic/375583
This is the topic from when it broke last time and was fixed: https://www.librarything.com/topic/375583
5bnielsen
>4 Nevov: Maybe something else broke too? The Links section where amazon links can normally be found also seems empty. (I,e, a random work: https://www.librarything.com/work/3577382/t/Harry-Potter-and-the-Deathly-Hallows has no links, which seems wrong.)
6Nevov
>5 bnielsen:
>The Links section where amazon links can normally be found also seems empty.
That's been mentioned in another topic today:
https://www.librarything.com/topic/378106#9199621
Edit: its own bug report for the above is at: https://www.librarything.com/topic/384438
>The Links section where amazon links can normally be found also seems empty.
That's been mentioned in another topic today:
https://www.librarything.com/topic/378106#9199621
Edit: its own bug report for the above is at: https://www.librarything.com/topic/384438
8waltzmn
>7 bergs47: So you don't report it? Then how are they to know? If there is a previous thread on the topic, then yes, post to that thread to say, "It's happening again," or cite the thread and add details. But never assume they know.
Programmers don't deliberately leave bugs -- or, at least, they may decide that "This bug is minor enough that we'll leave it for now," but they don't create buggy software on purpose. That's particularly true for LT, where there are only a few programmers (five!), and the code base is fairly large and the data set is huge. Keeping it all in mind is hard. Even were it true that they've seen the problem before, they might not remember. And you might have more data for them anyway that might help solve it.
Look at it this way: The programmers have limited time. If you gave them a little more information, they might possibly have been able to do the rest of the research themselves -- but that takes away from their ability to do other work. Every bit of research and work you do translates into saved time for the programmers, which leaves them free to do other programming work. That's a huge multiplier effect -- your research on your particular bug allows work that potentially helps thousands or millions of other users.
So it's a universal rule of bug reporting: Start with a summary, but then add the details. Maybe the summary will be all the programmers need. But if they need more, and you haven't supplied it, then they may be stuck. If they don't need more, it's only cost you a few minutes.
Programmers don't deliberately leave bugs -- or, at least, they may decide that "This bug is minor enough that we'll leave it for now," but they don't create buggy software on purpose. That's particularly true for LT, where there are only a few programmers (five!), and the code base is fairly large and the data set is huge. Keeping it all in mind is hard. Even were it true that they've seen the problem before, they might not remember. And you might have more data for them anyway that might help solve it.
Look at it this way: The programmers have limited time. If you gave them a little more information, they might possibly have been able to do the rest of the research themselves -- but that takes away from their ability to do other work. Every bit of research and work you do translates into saved time for the programmers, which leaves them free to do other programming work. That's a huge multiplier effect -- your research on your particular bug allows work that potentially helps thousands or millions of other users.
So it's a universal rule of bug reporting: Start with a summary, but then add the details. Maybe the summary will be all the programmers need. But if they need more, and you haven't supplied it, then they may be stuck. If they don't need more, it's only cost you a few minutes.
9timspalding
Marking as for @conceptDawg
10conceptDawg
>4 Nevov: Thanks for letting us know. It's likely that IMDb has changed their code again and we need to update our library to match.

