IMDb+ Plugin 2.1.0.291 with IMDb+ Scraper v4.9.xxx (1 Viewer)
- Thread starter RoChess
- Start date
Sweden
- March 10, 2006
- 4,434
- 1,897
- Thread starter
- Moderator
- #62
Hey @emphatic, looks like I have to rewrite a bunch of RegExp blocks as IMDb changed all their code again.
Gimme a few days to get through holiday celebrations, including a few movie marathon sessions, and I'll review all of them and push update out.
If everything goes correct I'll get my personal VPS restored as well
Gimme a few days to get through holiday celebrations, including a few movie marathon sessions, and I'll review all of them and push update out.
If everything goes correct I'll get my personal VPS restored as well
- March 10, 2006
- 4,434
- 1,897
- Thread starter
- Moderator
- #64
@emphatic, I just looked at your logs, and the regular expressions used by your IMDb+ version do not match the ones the latest version uses.
There is a bug in MovPic in which it updates the scraper-script, it shows the latest version in use, but in effect it uses an older version from the database.
The only work around I've found aside from a clean re-install on the database is to manually overwrite the badly indexed scraper-script entry with the latest one. It is a quick job that only takes a few seconds of copy-n-pasting, but you need to be willing to do so in the first place, or share your DB3 file with somebody willing to do it for ya.
If you DM me the database, I can do it for you, or I can explain the steps required in detail (done it before, so you can also dig up a previous forum post).
@ltfearme at one point was going to look at the code, but due to the total random nature it is a bitch to debug as there is no easy reproducible way to make it fail. That makes finding the offending source code a small needle in a big haystack, and right now there isn't even any indication as to what haystack it might be in.
Now your database is in the offending state, so perhaps @ltfearme will be able to use your database to not fix the source of the problem in not making the database become corrupt, but to at least fix it by obtaining the right scraper-script version. At least that way it is easier to debug and locate the issue, as it is reproducible with your database. I've looked at those before, and the latest version of the scraper-script is installed within the `script` table, but it is simply not used/read by MovPic when used to import movies with.
There is a bug in MovPic in which it updates the scraper-script, it shows the latest version in use, but in effect it uses an older version from the database.
The only work around I've found aside from a clean re-install on the database is to manually overwrite the badly indexed scraper-script entry with the latest one. It is a quick job that only takes a few seconds of copy-n-pasting, but you need to be willing to do so in the first place, or share your DB3 file with somebody willing to do it for ya.
If you DM me the database, I can do it for you, or I can explain the steps required in detail (done it before, so you can also dig up a previous forum post).
@ltfearme at one point was going to look at the code, but due to the total random nature it is a bitch to debug as there is no easy reproducible way to make it fail. That makes finding the offending source code a small needle in a big haystack, and right now there isn't even any indication as to what haystack it might be in.
Now your database is in the offending state, so perhaps @ltfearme will be able to use your database to not fix the source of the problem in not making the database become corrupt, but to at least fix it by obtaining the right scraper-script version. At least that way it is easier to debug and locate the issue, as it is reproducible with your database. I've looked at those before, and the latest version of the scraper-script is installed within the `script` table, but it is simply not used/read by MovPic when used to import movies with.
- March 10, 2006
- 4,434
- 1,897
- Thread starter
- Moderator
- #67
@emphatic, sweet.. I just wish there was a way to reproduce the issue so it is possible to actually get it fixed.. random bugs are the worst.. it happened to me only once, and that's after 100+ scraper-script updates, so that shows you how rare it is, but it sucks nonetheless when it happens
- March 10, 2006
- 4,434
- 1,897
- Thread starter
- Moderator
- #68
Getting back in the swing of things, so fixed two obvious mistakes.
IMDB+ v4.9.77 is latest as of right now.
@emphatic, ran into your issue myself earlier and it happened right after MediaPortal crashed to desktop. What I noticed was that in my database IMDb+ was referenced as 97 in the `scripts__source_info` reference table, but MovPic was using the very first entry (id = 476, source_info_id = 97, scripts_id = 276), and not the last one (id = 502, source_info_id = 97, scripts_id = 303). Will see if @ltfearme can assist in locating the code that is responsible for that. There must be some other reference that makes MovPic not look for the last entry correctly or something. I think it relates to when MovPic updates the internal scripts (like after a crash) each with a single reference entry, and then is not aware of previous scripts such as IMDb+ having multiple reference entries so only uses the first one.
Have a busy week ahead for work, but will look again next Sunday.
- Runtime works again. IMDb added multiple runtimes mainly catering to foreign releases which required expression to be updated
- Movies such as "Atomic Blonde" should import correct again and not as "The Cold City", because IMDb made multiple changes that I had to account for. This will require you to send those movies back to the importer in worst-case scenario if the title doesn't update on a quick refresh
IMDB+ v4.9.77 is latest as of right now.
@emphatic, ran into your issue myself earlier and it happened right after MediaPortal crashed to desktop. What I noticed was that in my database IMDb+ was referenced as 97 in the `scripts__source_info` reference table, but MovPic was using the very first entry (id = 476, source_info_id = 97, scripts_id = 276), and not the last one (id = 502, source_info_id = 97, scripts_id = 303). Will see if @ltfearme can assist in locating the code that is responsible for that. There must be some other reference that makes MovPic not look for the last entry correctly or something. I think it relates to when MovPic updates the internal scripts (like after a crash) each with a single reference entry, and then is not aware of previous scripts such as IMDb+ having multiple reference entries so only uses the first one.
Have a busy week ahead for work, but will look again next Sunday.
- Moderator
- #69
Interesting. I have another issue with MovingPictures, but I'm not sure if it's related to IMDB+:
Some movies are importing the same file twice, making the runtime twice as long. So when the movie ends, it starts over again. Also, this messes with the watched status as well. It might have to do something with the built in backup that MovingPictures does. I got so used to the database corruption before that so I always perform backups myself on a regular basis. This might also be a factor to what's causing issues, right? That I won't let MovingPictures take care of database corruption?
Emph
Some movies are importing the same file twice, making the runtime twice as long. So when the movie ends, it starts over again. Also, this messes with the watched status as well. It might have to do something with the built in backup that MovingPictures does. I got so used to the database corruption before that so I always perform backups myself on a regular basis. This might also be a factor to what's causing issues, right? That I won't let MovingPictures take care of database corruption?
Emph
- March 10, 2006
- 4,434
- 1,897
- Thread starter
- Moderator
- #70
MovPic never really takes care of corruption, although a few attempts been made. I probably should review the code on that section, because changes have been made to try.
Still, the automatic script I wrote to fix it when FanArtHandler was constantly corrupting the database is still effective. It simply runs an SQLite PRAGMA command to verify integrity and allows MediaPortal to launch if pass, or restore last-known good backup on failure. Whenever it passes integrity a fresh new backup is made, so it pretty much automatically takes care of everything. I'll be happy to search forum for the post with the script if you are interested as I posted it a long time ago.
Of course multiple entries on the same movie, might not mean a corrupt database, but simply importer confused on your files. Did you verify the movie entries, perhaps one got imported on some extension that you forgot to exclude. There are multiple ways to exclude them, from the extension list, to the noise filter.
Still, the automatic script I wrote to fix it when FanArtHandler was constantly corrupting the database is still effective. It simply runs an SQLite PRAGMA command to verify integrity and allows MediaPortal to launch if pass, or restore last-known good backup on failure. Whenever it passes integrity a fresh new backup is made, so it pretty much automatically takes care of everything. I'll be happy to search forum for the post with the script if you are interested as I posted it a long time ago.
Of course multiple entries on the same movie, might not mean a corrupt database, but simply importer confused on your files. Did you verify the movie entries, perhaps one got imported on some extension that you forgot to exclude. There are multiple ways to exclude them, from the extension list, to the noise filter.