Clarify TimeFrame switching and notify on user mistakes

[MaluNoPeleke]

I started collecting data with the default monthly view and everything looked fine:

Then I wanted to switch weekly view instead to have a more detailed timeline but this messes up the visualization of the data:

After switching back to monthly everything is back to normal so it seems that the data is stored correctly in the database but the logic to visualize it for the weekly option has an issue with it.

[Daandelange]

Yes this is absolutely normal behaviour. Sorry, I thought I documented somewhere that when changing the tracking period, one needs to start with a new db; but I can't find any reference of that (needs to be documented). In other words, the database is bound to the configuration's timeframe setting.
Simplestats is fundamentally simple, and the timeframeutility is at the core of its simple logic; what you are trying would require extra conversion utilities between differently-timeframed-databases.
If I remember correctly, there should be some protection on the tracking side (don't record mixed data if config setting doesn't match the db timeframe setting); but on the view side, this protection it hasn't made it to the panel. There could be something like that; particularly in the info tab.

[MaluNoPeleke]

Oh, I see, didn't expect that and thought it is just another kind of visualization. Do you have any plans to implement an automatic conversion between weekly and monthly so that you don't have to start from scratch again? I would like to keep the existing data and could live with the monthly view for a while.

[Daandelange]

Sorry for not documenting this, I understand the frustration. No plans at all working on it either, but a conversion script could be integrated.
In the DB upgrade mechanism (info tab) I wrote some "upgrade scripts" to help transition from alpha db structures to the newer ones, they could help you start writing a db conversion utility. Also have a look in the database file to see what's going on. (I'm using https://sqlitebrowser.org )

I can give some more insights in how it works so you better understand the logic.
Every 24H (by default), tracked user data is "crunched/sampled" into the time periods, to store the very minimal amount of data needed.
In weekly : 08-01-2021 --> all data is stored/accumulated in database period id = '202102' (week 2 of 2021).
In monthly : 08-01-2021 --> all data is stored/accumulated in database period id = '202101' (month 1 of 2021).
Note: In the database, the columns containing "period ids" are called monthyear (the first timespan that was available).
So say from 01-01-2021 to 07-01-2021, even in the weekly period, all data ends up summed in the same db row; you cannot see visits per day. Weekly --> the max precision is a week.
You can also think about writing a custom 'daily' timeframe utility; while I'm not sure how well that would perform; SimpleStats was coded with longer time frames in mind. Still a daily timeframeutility should be very simple to setup so it could be worth a try.

So if you'd like to convert your old data; you'd need to loop all monthly entries/rows in all tables, for each you divide the monthly values to a weekly average, then you store them as (about 4) separate rows with the corresponding weekly timeframe IDs, and remove the monthly row.

[MaluNoPeleke]

Maybe the database name could represent the time period if it is that important: simplestats_monthly.sqlite or simplestats_weekly.sqlite!?

[Daandelange]

Good idea. :)
Don't hesitate to share any findings regarding database conversions; I can help integrate it into SimpleStats.