Ride Count
Quote from thebritnickd on 25.04.2023, 15:12I am a relatively new user to Scenic (a couple of weeks) and I have been doing a number of 'test rides' to get a feel of the software and how to best use it for my needs by working out where it excels and where some shortcomings may exist. I have created a number of other posts on different topics where appropriate.
At this point, I have started to delete a number of the 'junky test rides' along the way to make sure I only record the rides I enjoy and want to keep for the future, whether that be to ride them again, maintain the nostalgia or forward them on to others.
As such I deleted the recorded rides until I had only 3 left that I could then do as I wish. To my dismay, however, I see that the number of rides reflected in the account statistics also now only reflects 3.
My preference is that this reflects 3 saved rides of ## total Scenic rides.
That absolute number of Scenic rides would likely trigger even more nostalgia, it would also encourage me to more proactively delete 'junky' rides as opposed to save them all (which could be in a junky folder).
The problem with keeping the junky rides is that it takes server space ($), if I add photos to them all then more server space ($$). Also, I will be more reluctant to look at old rides because of the amount of junk..... Junk expands to the space available.
But what about all the existing riders that have 600 rides, just to maintain the number..... Well maybe in the next release, that number is used as the total scenic rides and then any they delete won't come off that number...
The 'No. of rides' field as it stands reflects the number of saved rides, not the number of taken rides.
I am a relatively new user to Scenic (a couple of weeks) and I have been doing a number of 'test rides' to get a feel of the software and how to best use it for my needs by working out where it excels and where some shortcomings may exist. I have created a number of other posts on different topics where appropriate.
At this point, I have started to delete a number of the 'junky test rides' along the way to make sure I only record the rides I enjoy and want to keep for the future, whether that be to ride them again, maintain the nostalgia or forward them on to others.
As such I deleted the recorded rides until I had only 3 left that I could then do as I wish. To my dismay, however, I see that the number of rides reflected in the account statistics also now only reflects 3.
My preference is that this reflects 3 saved rides of ## total Scenic rides.
That absolute number of Scenic rides would likely trigger even more nostalgia, it would also encourage me to more proactively delete 'junky' rides as opposed to save them all (which could be in a junky folder).
The problem with keeping the junky rides is that it takes server space ($), if I add photos to them all then more server space ($$). Also, I will be more reluctant to look at old rides because of the amount of junk..... Junk expands to the space available.
But what about all the existing riders that have 600 rides, just to maintain the number..... Well maybe in the next release, that number is used as the total scenic rides and then any they delete won't come off that number...
The 'No. of rides' field as it stands reflects the number of saved rides, not the number of taken rides.

Quote from Guido on 25.04.2023, 15:20I understand. You are not the first one giving feedback around this. It's on the feature request list. Although it might seem simple it's actually not as this requires a database change, so it will take a bit more time to change this. Hope you understand.
I understand. You are not the first one giving feedback around this. It's on the feature request list. Although it might seem simple it's actually not as this requires a database change, so it will take a bit more time to change this. Hope you understand.
Quote from thebritnickd on 25.04.2023, 16:22I am assuming you add a field to the SQL database, maybe an update to the app itself can have the existing number copied to the new field and once it does it, then it displays the two numbers. (aka existing app users that did update the app only see the original field. Users that update the app modify the database for you and then display both fields in the app.) This may save you having to perform a major database update yourself, instead the app does it as users login with the updated app. Likely you'd need a flag somewhere to let the app know it did the operation for a given user.
LOL anyway i am engineering the problem now.... must let the coder code it themselves.... must let the coder code it themselves.... must let the coder code it themselves.
I am assuming you add a field to the SQL database, maybe an update to the app itself can have the existing number copied to the new field and once it does it, then it displays the two numbers. (aka existing app users that did update the app only see the original field. Users that update the app modify the database for you and then display both fields in the app.) This may save you having to perform a major database update yourself, instead the app does it as users login with the updated app. Likely you'd need a flag somewhere to let the app know it did the operation for a given user.
LOL anyway i am engineering the problem now.... must let the coder code it themselves.... must let the coder code it themselves.... must let the coder code it themselves.
Quote from Guido on 25.04.2023, 17:25That's the gist of it yes 😊 . Still, messing with the database (and syncing mechanism as a result) is error prone, and will have to be tested thoroughly as consequences of bugs can be severe.
That's the gist of it yes 😊 . Still, messing with the database (and syncing mechanism as a result) is error prone, and will have to be tested thoroughly as consequences of bugs can be severe.



