search

ltguillaume / droidshows

A Reboot of DroidSeries Offline TV Shows Tracker
https://codeberg.org/ltguillaume/droidshows
GNU General Public License v3.0
84 stars 20 forks source link

[FR] Wishlist, New Fork #108

Open warren-bank opened 2 years ago

warren-bank commented 2 years ago

I've only just recently found this app. I'm absolutely loving it. Great job!

Here are a few suggestions for improvements:

warren-bank commented 2 years ago

did you?:

  1. uninstall the previous version and then fresh install the newer version
    • which would delete the current database
  2. install the newer version as an update to the previous version
    • which wouldn't touch the current database,
      whose version is already current and wouldn't require any kind of further update
warren-bank commented 2 years ago

oh.. one thought..

I'm not sure which version of the app it was that made this transition.. but up until some point, the name of the database file was: "DroidShows.db".. and in a fairly recent update, its name was changed to: "TV-Tracker.db"

this naming convention is used both for backups and the internal database used by the app. if you updated from pre- to post-.. then that would explain why the newer version of the app couldn't find the old database.

if I had more users than only yourself..
then I'd consider adding some code to detect an internal database using the old filename..
and renaming it; so this change wouldn't effect the user.
But.. I'm lazy.. and I hope that you'll forgive me :smile:

warren-bank commented 2 years ago

now that you've caused me to reconsider this decision.. in terms of how it might interfere with users of "DroidShows" who might wish to use this app.. here are my thoughts:

Ibuprophen commented 2 years ago

I'll clarify some items @warren-bank... 👍

1) I currently have both the DroidShows and TV Tracker installed.

The DroidShows backup directory is "DroidShows1" and the TV Tracker directory is "DroidShows".

I had previously (without an issue) successfully changed them both.

2) Regarding the issue I just reported...

I already had "TV-Tracker-008.00.07-09API-release" installed and restored (as previously reported) from the database you provided.

Today, I had downloaded "TV-Tracker-008.00.08-09API-release" and then simply updated the app.

After updating the app, I launched it and found that, after the update, the information for the shows somehow disappeared.

I then performed a restore from the backup directory (already associated with the TV Tracker) and it restored without any problems.

I hope I had explained the above okay via text...

~Ibuprophen

warren-bank commented 2 years ago

hmm.. looking at the history of commits.. pre < tmdb/008.00.07-09API post >= tmdb/008.00.07-09API

since you updated from post to post..
this change wouldn't have effected you.

that's very odd..
I've updated a million times and it's never wiped the database.

thinking about it in terms of how the database could be deleted, either:

Ibuprophen commented 2 years ago

@warren-bank, just letting you know what happened on my end... 👍

I'll just keep what I have with your latest version installed and the database good to go.

When you release a new update, I'll just keep installing as an update and report back.

Thanks a Bunch! 💯

~Ibuprophen

ltguillaume commented 2 years ago

Ok, so using v008.00.08-09API, I tried to migrate my personal database (which has 291 shows, a lot of them backlisted) and ran into problems:

  1. After telling the app to restore the database, I got back into an empty shows list, and nothing seemed to happen, for a full minute.
  2. I then closed the app and reopened it. It started to migrate the database. Each show took over a minute to be updated. I see tens of lines like this: 
    I/chatty  (20188):  uid=10137(com.github.warren_bank.tiny_television_time_tracker) expire 19 lines
I/chatty  (20188):  uid=10137(com.github.warren_bank.tiny_television_time_tracker) expire 761 lines
W/System  (14229):  A resource failed to call end.

    and hundreds of this:

    D/themoviedbapi(20188):  Method: 'episode', Sub-method: '', Params: TmdbParameters[parameters={APPEND=external_ids, EPISODE_NUMBER=23, ID=63174, LANGUAGE=en, SEASON_NUMBER=3}]
D/themoviedbapi(20188):  URL: http://api.themoviedb.org/3/tv/63174/season/3/episode/23?api_key=c9eb196aaf70baf91d4ce4f0fea6a360&append_to_response=external_ids&language=en
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Doug Savant'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='8.561'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Colin Egglesfield'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='8.789'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='J. Anthony Pena'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='7.339'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Terrell Tilford'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='3.018'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Emma Bell'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='9.364'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Alice Kwong-Van Dusen'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='0.68'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Aidan Gail'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='3.109'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Amelie Leviant'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='0.6'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='adult' value='false'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='known_for_department' value='Acting'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='original_name' value='Tory N. Thompson'
D/themoviedbapi(20188):  MediaCreditCast: Unknown property='popularity' value='2.091'
D/themoviedbapi(20188):  TVEpisodeInfo: Unknown property='runtime' value='null'
  3. After a lot of time, only ~20 shows were migrated and the app was killed by the OS (granted, it was in the background, but it was already processing my database for over an hour): 
    I/ActivityManager(844):  Killing 20188:com.github.warren_bank.tiny_television_time_tracker/u0a137 (adj 700): excessive cpu 43450 during 300085 dur=686068 limit=10
I/WindowManager(844):  WIN DEATH: Window{fe0d442 u0 com.github.warren_bank.tiny_television_time_tracker/com.github.warren_bank.tiny_television_time_tracker.DroidShows}
  4. I restarted the app and I got the toast that an error occurred when updating the database: 
    I/ActivityManager(844):  Start proc 3124:com.github.warren_bank.tiny_television_time_tracker/u0a137 for pre-top-activity {com.github.warren_bank.tiny_television_time_tracker/com.github.warren_bank.tiny_television_time_tracker.DroidShows}
D/TV-Tracker(3124):  Database update routine
D/TV-Tracker(3124):  Current database version: 0.1.5-7G5
D/TV-Tracker(3124):  Current database version: 0.1.5-7G5
I/SQLiteConnectionPool(3124):  The connection pool for /data/user/0/com.github.warren_bank.tiny_television_time_tracker/databases/TV-Tracker.db has been closed but there are still 1 connections in use.  They will be closed as they are released back to the pool.
E/TV-Tracker(3124):  Error populating TVShowItems or no shows added yet
W/System.err(3124):  java.lang.IllegalStateException: attempt to re-open an already-closed object: SQLiteDatabase: /data/user/0/com.github.warren_bank.tiny_television_time_tracker/databases/TV-Tracker.db
W/System.err(3124):     at android.database.sqlite.SQLiteClosable.acquireReference(SQLiteClosable.java:57)
W/System.err(3124):     at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1439)
W/System.err(3124):     at android.database.sqlite.SQLiteDatabase.rawQuery(SQLiteDatabase.java:1382)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.SQLiteStore.query(SQLiteStore.java:95)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.DbGateway.createTVShowItem(DbGateway.java:674)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.DbGateway.createTVShowItems(DbGateway.java:708)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.DroidShows.getSeries(DroidShows.java:1754)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.DroidShows.getSeries(DroidShows.java:1745)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.DroidShows.onCreate(DroidShows.java:309)
W/System.err(3124):     at android.app.Activity.performCreate(Activity.java:7824)
W/System.err(3124):     at android.app.Activity.performCreate(Activity.java:7813)
W/System.err(3124):     at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1306)
W/System.err(3124):     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3245)
W/System.err(3124):     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3409)
W/System.err(3124):     at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
W/System.err(3124):     at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
W/System.err(3124):     at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
W/System.err(3124):     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
W/System.err(3124):     at android.os.Handler.dispatchMessage(Handler.java:107)
W/System.err(3124):     at android.os.Looper.loop(Looper.java:214)
W/System.err(3124):     at android.app.ActivityThread.main(ActivityThread.java:7356)
W/System.err(3124):     at java.lang.reflect.Method.invoke(Native Method)
W/System.err(3124):     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
W/System.err(3124):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:940)
D/TV-Tracker(3124):  Database update routine
D/TV-Tracker(3124):  Current database version: 0.1.5-7G5
D/TV-Tracker(3124):  Current database version: 0.1.5-7G5
D/TV-Tracker(3124):  Database needs update
D/TV-Tracker(3124):  Current database version: 0.1.5-7G5
D/TV-Tracker(3124):  UPDATING TO VERSION 0.1.5-7G6
E/SQLiteLog(3124):  (1) no such column: serieName
E/SQLiteLog(3124):  (1) no such column: serieName
W/System.err(3124):  android.database.sqlite.SQLiteException: no such column: serieName (code 1 SQLITE_ERROR): , while compiling: INSERT into tmdb_migration_series   SELECT NULL as tmdbid, cast(id      as INTEGER) as thetvdbid, serieName as name, language, passiveStatus as archived, 0 as pinned, extResources FROM series
W/System.err(3124):     at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method)
W/System.err(3124):     at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:986)
W/System.err(3124):     at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:593)
W/System.err(3124):     at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:590)
W/System.err(3124):     at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:61)
W/System.err(3124):     at android.database.sqlite.SQLiteStatement.<init>(SQLiteStatement.java:33)
W/System.err(3124):     at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:1805)
W/System.err(3124):     at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1733)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.SQLiteStore.execTransaction(SQLiteStore.java:119)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.Update.doTmdbApiMigration(Update.java:543)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.Update.doTmdbApiMigration(Update.java:420)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.Update.update_version_007(Update.java:331)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.Update.updateDatabaseVersion(Update.java:233)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.Update.access$300(Update.java:34)
W/System.err(3124):     at com.github.warren_bank.tiny_television_time_tracker.database.Update$1.run(Update.java:114)
W/System.err(3124):     at java.lang.Thread.run(Thread.java:919)
D/TV-Tracker(3124):  Current database version: 0.1.5-7G5
E/TV-Tracker(3124):  Attempt to update version of database schema has failed
I/AyncSED (16526):  end task=8b020d view=5294aa9 tag_iconTask=8b020d cacheId=`app://com.github.warren_bank.tiny_television_time_tracker/com.github.warren_bank.tiny_television_time_tracker.DroidShows0`
warren-bank commented 2 years ago

@Ibuprophen

warren-bank commented 2 years ago

@ltGuillaume

offhand, the only condition that I can think of that could cause migration to fail.. which I haven't written code to prevent.. is if in your DB.. the series table were to include more than one row for any distinct "id" value. If I remember, the old schema didn't have any constraints to prevent this; whereas, the new schema treats this field as a primary key.

care to share you DB file?
..so I can run it in the debugger;
unless you happen to know by looking at which shows did migrate..
which series is the one that causes things to break?

warren-bank commented 2 years ago

PS: I updated my own full list of series last night.. which required the update to v8.0.8. My list has 140 series and although I wasn't watching the clock.. it didn't seem to take too long.. maybe an hour. It resulted in a dialog that pointed me to a log file, which listed the 3 series that couldn't be found.

PPS: I did the migration on a new/previously-untested Android device.. a TV box running Android 7. Everything went smoothly.

Ibuprophen commented 2 years ago

Just a quick heads-up @warren-bank that I had just updated the TV Tracker app to "TV-Tracker-008.00.09-09API-release" and nothing was (apparently) affected as all the shows remained untouched.

As always, I'll keep you posted on any issues and such as I encounter them.

Thanks a Bunch!

~Ibuprophen

warren-bank commented 2 years ago

that's a relief.. my guess is that when you did encounter a problem.. you'd updated from 8.0.6 rather than 8.0.7.. that would explain it.. but.. ??

in any case, regarding 8.0.9.. its purpose was to replace the styles without actually changing how it looks (too much).. the old styles caused a very weird problem on one of my boxes, and this fixes it.. question to you is.. does it look OK? I don't really have an eye for UI.. for me UI is either usable or unusable.

Ibuprophen commented 2 years ago

I'm not sure if this can be done, but I just thought of this suggestion...

Since there's only so much room for the Show Title and the longer ones tend to end with "...". This isn't a big deal with me personally.

I was just curious if the image can be reduced/resized down a touch and allow for the title to be moved to the left a bit. This would allow for the additional text of the Show Title to be viewed.

It's a challenge to explain, but I had created the following image to help with what I'm referring to.

TV Tracker - Suggestion Example 1

I do hope that my text and example image explains my suggestion okay.

Thanks a Bunch! 👍

~Ibuprophen

warren-bank commented 2 years ago

if the title was elevated to a full-width row above the image, then the overall height of each item in the list would increase.

however, I'm thinking that allowing the title to wrap to additional line(s) wouldn't be such a bad idea. Any thoughts?

ltguillaume commented 2 years ago

I agree with @Ibuprophen. I understand the appeal to have the covers a bit larger than originally in DroidShows, simply because they're more helpful to recognize the show if they're a bit bigger, but I feel they're way too big right now.

if the title was elevated to a full-width row above the image, then the overall height of each item in the list would increase.

Could still work if the cover was smaller, but I don't think it'd be necessary if the cover would be resized to somewhere between the current and the old size.

however, I'm thinking that allowing the title to wrap to additional line(s) wouldn't be such a bad idea. Any thoughts?

I'm afraid that'll look really bad.

warren-bank commented 2 years ago

I'm not married to the current sizing logic.. but to summarize exactly what it is:

this discussion seems to imply that we could decrease the height without affecting the width.. which would require cropping.. which (based on my earlier testing) looks really bad.

regarding truncating the names of series.. I'm much more prone to show the entire name.. as this is vital information to a user; which (imho) is more important than a question of aesthetics.

to be perfectly honest.. I never noticed the truncating of series names in my own usage.. because I always use this app on a large TV screen.. on which it's a non-issue. But on a small-screen device, I would expect to see all of the important details.

Ibuprophen commented 2 years ago

Just as @ltGuillaume had mentioned, I do like having the image solely for a quick recognition of the listed series,. Resizing them down would be a good thing to me, but not too small... LOL!

I'm more of a Simplistic & Functional person for certain apps like this.

Adding a 2nd line would be a good idea, but wouldn't it be better for the app to recognize that the title required it so those series that doesn't need it would remain using the single line?

Also, if the title text would be resized, maybe changing the color would allow it to stand out a bit more (not referring to something like yellow that would just abuse the eyes a bit... LOL!).

1 more thing regarding the image, I'm only referring to the list itself. The image in the series details is fine as the full title is already good to go.

I hope I had explained this okay via text.

~Ibuprophen

warren-bank commented 2 years ago

well.. I can only speak to my own personal preferences.. but I rather like the sizing of the images as it is now; it looks good on my smallest handset.. and it looks good on my largest TV.

regarding the text.. I just released a minor update that allows the title to span up to 3x lines (but only if necessary). I'm not eager to change: font, color, size, etc.. I rather like it how it is. (ie: keeping it simple and clean)

warren-bank commented 2 years ago

i honestly didn't think anybody would feel so strongly about image size..

what I could do.. is to move the max width (as a percentage of screen width) to a user preference.. which would default to 20%

however, my concern is what to do when a user changes this value? if the value is decreased, then the app could resize all of the current images (on disk). but.. if the value is increased, then?? ..do we delete all of the current images (on disk).. and redownload/resize a new image for every series?

that seems like a whole lot of work (for the app to perform).. for very little reward. idk..

although.. come to think of it.. the width that a user can choose for the listview image could be constrained.. such that it cannot be larger than the image used on the series description (ie: 200dp / 33%).. which would allow the listview image to always be regenerated by resizing the larger/series image.. which removes the need to redownload.. so if the allowed range were.. lets say.. 10% to 33% which would produce a resized image having a width that is the smaller of: 100dp or (XX%)(screen width in portrait) ..I think that could work

ltguillaume commented 2 years ago

I think it would be a good idea to look into just using a single cache for the images, without having to recreate all the thumbnail images:

  1. I believe the "medium size" images already have bigger dimensions than necessary, even for the show details activity
  2. You could just resize them to that maximum size in the show details and give the user the option to scale down from there for the shows list, by only changing the dimensions in the getView(), not by having another set of thumbnail files. Pretty sure it's gonna be enough for your out-of-memory issue to do it like that, too.
warren-bank commented 2 years ago

personally, I don't like the idea of dynamically resizing images in a list view.. where each row that gets loaded requires all of that extra work; I like the current methodology much better.. which is to know exactly what size(s) each image will be displayed at.. resize them once (per size).. and load them (as needed) without any dynamic resizing or scaling.

sure.. it requires a little extra disk space on the frontend.. realistically, very little.. and it saves a ton of cpu load and memory on the backend.

to be perfectly honest.. I really kinda hate the idea of allowing the user to change the image size.. if it becomes an issue that gets enough interest, then I'll add it.. but for now.. I'm going to hold off

Ibuprophen commented 2 years ago

@warren-bank, I had just updated to the "TV-Tracker-008.00.10-09API-release" and its much better.

The size of the images are fine for myself and I'm very happy that the longer full series titles are viewable (based upon my list of shows). Thanks a Bunch!

I did notice something else that applies to both from @warren-bank & @ltGuillaume.

When an alternative backup directory has been established successfully, it (apparently) only changes when manually backing up.

When you select the "Automatically perform daily backups" opinion, that still utilizes the default directory.

I hope I had explained this okay via text.

~Ibuprophen

ltguillaume commented 2 years ago

@warren-bank, I had just updated to the "TV-Tracker-008.00.10-09API-release" and its much better.

The size of the images are fine for myself and I'm very happy that the longer full series titles are viewable (based upon my list of shows). Thanks a Bunch!

I did notice something else that applies to both from @warren-bank & @ltGuillaume.

When an alternative backup directory has been established successfully, it (apparently) only changes when manually backing up.

When you select the "Automatically perform daily backups" opinion, that still utilizes the default directory.

I hope I had explained this okay via text.

~Ibuprophen

I can't reproduce this with my fork.

warren-bank commented 2 years ago

I can't reproduce it either:

ltguillaume commented 2 years ago

@warren-bank Just so you know, HH:mm seen was an explicit request by a user. I think the amount of episodes seen is also useful, but it could just as easily be combined into something like Episodes seen: xx (about XhXXm).

warren-bank commented 2 years ago

v8.0.12 adds a new option that allows the images in the ListView to be dynamically resized.

the approach is kind of a "best of both worlds" solution.. by default, images are resized upfront and presented without any additional scaling. using this option, images can be dynamically resized at runtime (by configuring attributes of the ImageView). so.. it's up to the user to choose which resizing strategy they would prefer to use.

Ibuprophen commented 2 years ago

@warren-bank, I just wanted to let you know that everything has been working well as of today's release.

Though I can't state this for every single feature since I don't typically use all of them myself.

Thanks a Bunch! 👍

~Ibuprophen

ltguillaume commented 2 years ago

@warren-bank I was thinking about https://github.com/ltGuillaume/DroidShows/issues/108#issuecomment-1153019223 and your remark

  • if the season finale of a series airs tonight, then:
    • next unaired episode = 6 months from today

which is not true for my fork, so I thought maybe you've changed the behavior there. But judging from https://github.com/warren-bank/Android-Tiny-Television-Time-Tracker/blob/dc5614636a6f374f903f62936399c920ad6d5767/android-studio-project/TV-Tracker/src/main/java/com/github/warren_bank/tiny_television_time_tracker/database/DbGateway.java#L944 it's still the same.

Ibuprophen commented 2 years ago

@warren-bank, I had just updated the app to "TV-Tracker-008.00.16-09API-release" and, when I performed an update to the shows, it was updating slowly and then crashed halfway through.

Here's a Screenshot and a Crash Report (hoping they're helpful).

Crash Screenshot - TV-Tracker-008 00 16-09API-release

Crash Report - TV-Tracker-008.00.16-09API-release.txt

The prior version gave me no issues.

Thanks a Bunch!

~Ibuprophen

warren-bank commented 2 years ago

interesting.. my guess is that this API method returns null instead of a (potentially empty) List

suppose I should wrap the loop within a test to check that the List is non-null..

I'm curious which episode in which series raised this error?..

I'm currently re-migrating my entire 140-series database.. about half-way through right now.. but haven't encountered any errors.

update:

ltguillaume commented 2 years ago

@warren-bank Apparently there's a lot more going on in terms of database transactions with the TMDB implementation. I think you could vastly improve the performance by

  1. not disabling WAL (db.disableWriteAheadLogging()) This does mean, however, that you'll have to start creating checkpoints before backing up (PRAGMA wal_checkpoint(full)) or use SQLite's backup API (https://www.sqlite.org/backup.html) in order to create backups (not sure how to implement that).
  2. (probably) using more db.beginTransaction();/db.setTransactionSuccessful();/db.endTransaction(); to write to the database in batches.
warren-bank commented 2 years ago

@Ibuprophen new version fixes the problem.. thanks for letting me know.

Ibuprophen commented 2 years ago

Just updated it and no issues experienced @warren-bank.

Thanks a Bunch! 💯

~Ibuprophen

warren-bank commented 2 years ago

@ltGuillaume

references:

observations:

ltguillaume commented 2 years ago

@warren-bank I know that. I added disableWriteAheadLogging() because the amount of db operations wasn't that big and performance was okay. But there's much to gain with this new implementation.

I know for sure that this was needed, but some Android versions had WAL on by default, some didn't, AFAIK. So I needed to add this when I switched to a newer Android version in order to quickly fix backups.

AFAIK it's supposed to be faster because it doesn't have to write changes to the main database every time, but logs it (in a separate small file) and then commits it in batches to the main database file.

warren-bank commented 2 years ago

well..

currently.. during migration:

in theory it would be possible to rewrite the migration code to:

then.. resuming sequential processing

however, personally.. I have no interest in implementing parallelization;
I just don't see migration as that important..
it works pretty well as it is, and that's good enough for me.

ltguillaume commented 2 years ago

Do you have evidence that the fact that the code isn't multithread is the actual bottleneck, instead of the (amount of) database queries? Or more specifically, the writing-to-the-database because of the amount of separate queries?

warren-bank commented 2 years ago

the time to execute each DB update.. nanoseconds the time to download and parse 100+ API requests w/ JSON response payloads per series.. minutes

for each series:

so:

I don't really think that evidence is needed..
but feel free to run some benchmarks to compare the relative amount of time spent performing download/parse vs. DB insert

warren-bank commented 2 years ago

totally off-topic.. but it's been a productive week; I wrote another app that you two might find useful.. and just released an initial version. a few additions/enhancements are in mind for near-term updates.

Charles7z commented 2 years ago

Just to add a little info.

I just installed DroidShows and Tiny... I started with DroidShows, loaded all my TV shows, about 60, etc. Then discovered the fork, installed it, restored from DroidShows backup — Tiny... then downloaded the shows, it was very slow the first time, I've refreshed a couple times with each app and Tiny takes about 3x longer, still under a minute.

Note that I'm on rather slow data so it's noticeable.

Just thought you might want to know. And thanks for continuing this app, amazing I just found it 🤦‍♂️

Ibuprophen commented 2 years ago

@Charles7z, Upon the 1st restore of the Droid Shows database, it will take quite some time to accomplish as mine took around an hour with a little over a dozen shows.

Once this first restore is done, everything should work out much faster.

This is only because the TV Tracker App uses a more up-to-date API as well as reworked coding.

So the initial import is only converting the Droid Shows database information using the current API that will always result in this slow import.

It's hard to explain via text, but maybe @ltGuillaume and/or @warren-bank will be able to provide a better explanation.

Please Enjoy! 👍

~Ibuprophen

ltguillaume commented 2 years ago

@Ibuprophen it took an hour for a bit over 12 shows? That's crazy! 😉

Charles7z commented 2 years ago

I've tested a lot of move/TV tracking apps and none have every taken an hour to sync, and they are synching thousands..... Cathode which keeps a good amount of info for offline doesn't even take that long.

I'm thinking something was wrong with that particular sync.

On a side note....

Does anyone know of a similar app for movies? Something that's offline. Everything I've found required account login or doesn't keep data for offline viewing.

Thx again

jmichael2497 commented 1 year ago

just spotted and browsed across all this, looks like i encountered mostly already known issues, except it seems like restore of 5MB (90 shows) DroidShow backup from F-Droid 7.11.2 still not working for me (missing watched status) in LOS (A13) so opened issue.

A4T restore missing watched status