One more suggestion to make the integration with beeminder sturdier. I tried to mess with the goal where the datapoint is sent by introducing an external point.
Since the code couldn’t parse the datapoint comment to update it, it just did nothing, the ping was lost.
1726668044 TagTime ping: test [16:00:44] 66eadd13d4865fb88db7b978 2024-Sep-18 entered at 16:00 by scarabaea via Beedroid 0.0
2024-09-18 parsed datee
2024-09-18 today
The date is today! should update the datapoint with id of latest ping
I need auth_token, goal, tags, id
TagTime ping: test [16:00:44]
invalid literal for int() with base 10: 'TagTime'
But non-typical datapoints that cannot be parsed can happen not only because of my intentional messing with the data. Derailments, for example? Any other potential case where the user has edited the datapoint comment.
So, I would suggest, there should be an exception to this error that opts to create a new datapoint if the previous one cannot be parsed for whatever reason. (Like I imagine a new one would be created if the previous datapoint’s date is not today?)
Fixed, seperate the tags that match to goals with spaces instead of commas now.
I just adjusted the logic for this aswell. It was checking to see if there are colons " : " in the datapoint, and then it would attempt to increase the ping counter for the number before the colon, without checking to see if there are even any valid numbers before the colon. Made a few adjustments and it should work properly now.
For example:
if your datapoint is “TagTime ping: test [16:00:44]”, and you answer a new ping with just “test”, your datapoint now becomes “2 pings: TagTime ping: test [16:00:44], test”
Test this out and let me know what you get!
Also you are correct, if you answer a ping, and your most recent datapoint is not the same day, it will create a new datapoint for the current day. So if you answer a ping with “test” your datapoint is going to be “1 ping: test”
Were you able to get it working without running a virtual environment? I know the easiest solution to the “externally-managed-environment” problem is by using a virtual environment, but it really shouldn’t have to be done. Maybe the way that you’ve set up your python frameworks is causing this problem, honestly not too sure.
Another way you could run it, is that since the libraries you need are installed on python 3.11, you can try running the application with that version instead of python 3.12.6
Great! Thanks for addressing all the suggestions so quickly. Everything I tried is running smoothly for me now. I will continue to test in some more real-life settings, maybe will run into more improvement suggestions. So far the only thing is that once the log has reached a longer number of pings, it takes a while to load. I am not sure though if it takes this time to load the visible 100 or it loads everything in the log somewhere in the background. If it is only for 100, maybe it might be helpful to limit the number of entries on a page to a lower number, like ~25, IDK. (How many might a person realistically want to see immediately without “turning a page” when they return to computer after several hours AFK?)
Okay, here’s something marginal but potentially exploitable by cheaters
As far as I understand, when you change the ping frequency, it will be changed after the nearest ping, right? So the nearest ping will still come on the schedule for the previously set ping frequency? But I just realized that the datapoint for this next ping will already reflect the new set frequency.
E.g. I had it set to 5 min => changed to 15 min. The next ping that was already on the way (judging from the countdown) came, and then the submitted datapoint was +0.25, i.e. = 15 min.
I understand it is a very marginal situation If you decide not to deal with it, I will just remove this comment from the thread so that this loophole is not announced for posterity
It shouldnt take long at all to display the visible 100, I noticed that when I would open up the log editor with a log that has around 1000 pings, it would be very quick, but then opening up a log that has around 200,000 pings would take 2-4 seconds to open up. Displaying the visible 100 isn’t the problem, but instead what is happening is that before the window is displayed, it runs through every line in the log, adds each line to an array, while also grabbing each unique tag so that the “search tags” option menu displays all of the searchable tags.
Doing it this way-
Pros: able to see all of your tags in the “search tags” menu. Once you do search for a tag, it can instantly grab all of the pings that include said tag, without having to iterate over the log file again.
Cons: Slow startup time on big log files
Definitely some room for improvement and optimization here! I’m just not exactly sure how I want to go about it. One possible solution would be to only have the log viewer read the log file 100 lines at a time, only iterating through the entire log when you try to search up a specific tag, but this would remove you being able to see all of the individual tags, and would cause searching up a tag to take 2-4 seconds, in return for instantly booting up the initial window.
Let me know what you think.
This is definitely interesting. If you change the gap while tagtime.py is running, you are no longer on any universal schedule until you restart the main program, because you could’ve been on the 45 minute gap universal schedule, and then changing it to 15 wouldn’t put you on the 15 minute gap universal schedule, and instead it would be a hybrid schedule (make sense?)
Instead I could call for a restart of the application as soon as you change the gap, so that when the program reboots, it properly puts you on the 15 minute gap universal schedule (as it will iterate through every ~15 minute ping from the start time Original TagTime creation unix timestamp up until the current time)
However I don’t know how much of a problem this really is, and I don’t expect people to be constantly changing their gap, but then again would be good to cover the bases.
EDIT: i could also just have the main program check the previous gap compared to the current gap once a ping is supposed to come up (or since I have the countdown check it’s time every 10 seconds, I can do this gap check on the 10 second mark, so that if you were to change the gap you wouldn’t have to wait for your previous gaps ping to come up and it would instantly restart the countdown), and if the gap is different, restart the countdown and put you on the new gap schedule, so no restart of the application would be required.
Oh, I see. I thought the slowdown is about populating the visible 100 because I can see how the scrollbar is becoming smaller while the app is unresponsive.
If the culprit is running through all of them for search purposes, the question is then whether it will be a major user-noticeable obstacle when the entire log is many months’ data instead of just 200+ entries. Is searching by tags something a user would do very often when they pull up the log? In my case, I imagine the most frequent use cases for pulling up the log would be answering the AFK pings and copying a line of tags without retyping them (I know of " as the way to copy the latest entry but let’s say it’s a line of tags from one of the other recent entries). Searching is something I would use once in days maybe. But I agree there might be other use cases, with more frequent use of searching.
I don’t know if it’s a frequent situation either. I haven’t really been changing the ping frequency on my Android app at all since I started using it again after a pause several months ago. 15 minutes it is. But I am only using it for one project, for which 15 min seems to be a sensible granularity.
Your idea to check if anything changed about the ping frequency during the countdown seems the best one to me. I realize I initially pointed to a different discrepancy (the datapoint reflects the new setting but the schedule is still for the previous setting), but checking sometime during the wait time and switching to a different schedule as soon as the change is noticed seems even better. Anti-magic, or how was that principle called As soon as a setting is changed, the user expects it to be applied in all aspects.
I really hope more people will join the testing! Because it feels like these things that I am bringing up now are really marginal cases while other people may run into some other more central things with their different usage patterns and expectations of such an app.
The Principle of Least Astonishment/Surprise I believe. I agree that this is probably best, all of the other settings that you can change are instantly applied, this shouldn’t be any different. Will make that adjustment on the morrow.
I hope so too! It’s only been 1-2 days with you testing and already you’ve shown me great ways to improve upon the app, aswell as things that I’ve missed. Like changing the beeminder tags to using spaces instead of commas, I can’t believe I missed that! Also the silent modes are huge! I’ll be playing video games, and get interrupted in the middle of something intense, and I’m like “damnit TagTime not right now!” and would just completely quit the application until I either restart my PC or am done playing games, but now I can just set it to silent mode! Would’ve taken me awhile to think of that on my own. I appreciate all the testing you’ve put in so far, seriously! I have bigger dreams for TagTime, and more testers will go a long way!
In regards to the Log Viewer, I’ll keep it how it is now until we get more opinions. That is a big rewrite of the code for such a seemingly small change.
@scarabaea at a wedding over the weekend, haven’t forgotten about the gap changes. But i do wanna ask if you would be so kind as to send screenshots of the current tagtime android app. Gonna try my hand at recreating it with the new system.
@CortTheWart, no worries about the gap changes. It’s not like I am changing them back and forth all the time. It was mostly a suggestion for a future improvement.
Toggles the selection on and off. So I don’t have to retype every time, I can select from existing ones (or a type a new one, through the “use keyboard” option)
I have never done either, so I can only guess. Maybe deleting just logs as opposed to “all data” keeps the set-up connections to beeminder goals.
Initiates a sharing event, I can then choose with what app I share, not just email.
If there are tags that have been created but then deleted from any pings, they are still in the list of all tags that can be reused on screenshot number 3; so this button, I imagine, cleans those. (Not sure I ever used it either.)
Only if the phone is off or the notifications are off (=silent mode), it automatically adds “OFF” tag. These pings that appear empty I just didn’t bother to respond to, as I am currently only using tagtime for one project. I think “AFK Retro” is redundant because, technically, any ping on the phone is AFK. It just pops up as a notification, I hear it, grab the phone, unlock it, respond to it. Or I am in a different app on the phone at the moment and the notification comes in the background. The developers will know better but I can imagine it is something about the permissions for an app to show a ping on top of whatever was on the screen and wait for a response, and only then assign AFK if the response didn’t come immediately - well, none of this is part of how this app functions
@CortTheWart, here is something else that I ran into. Potential bug report but also might be misunderstanding on my side on what to expect.
I have been running the app for a while at that moment, there was 800+ seconds left until the next expected ping. Then I needed to restart the file, which didn’t take more than a minute. Upon restart, the check for missed pings suggested that I missed two (by timestamps, all fell within that period when the countdown to that ping that end with “810 seconds left” was already running). Moreover, the next was now expected in 217 seconds instead of 700-something.
This is really unexpected, because all the idea with a universal “initial start” and the pings missed while off - all this suggests that everything is on some kind of a universal schedule. Is it though? (I did not change the settings for ping frequency on this run.)
Here’s a excerpt from the terminal.
860 seconds left
850 seconds left
840 seconds left
830 seconds left
820 seconds left
810 seconds left
C:\Users\darya\Documents\CloudTagTime-main\CloudTagTime-main>python tagtime.py
Catching up since last ping...
1184097393 initial start time
1727943855 initial last ping time
1727944923 now
1727944193 start time
you missed 2 pings!
Next ping at 1727945142, which is in 217.00 seconds.
I noticed this as well. I need to figure out why exactly it’s happening, but everytime you do a catch-up, or a first time startup, it correctly uses the universal schedule up until your first actual ping. As soon as the first ping is answered, and you go onto the next ping, it goes off schedule, even though it should be using the same method to grab the next ping time. I found this out when running the program for a first time startup on two seperate devices at the same time. The first ping will pop up at the exact same time, any pings after that are different from each other, and the two devices won’t be pinged at the same time. Definitely need to figure that out.
Also I know I’ve been MIA for a little bit, been learning a new coding language to try to build the android version of it. Thank you for the update, i’ll be looking into it.
@scarabaea I have updated tagtime.py with a few changes.
The most important:
I have successfully recreated Perl’s random algorithm and the math used for getting the next ping time from the original version of TagTime. The universal schedule should now be the exact same between the original and my version. So in the case of you using my version, as well as the original android app, they should both be pinged at the same time.
I have also fixed the program going off-schedule after a single ping, it is now consistently on-schedule the entire time it runs.
Here are the upcoming ping times for the next 2 days that I calculated with the new algorithm. They should be the same for you when running it, and they should also be the same as the original TagTime program (hopefully someone can approve that):
This looks really impressive.
I can confirm that I am receiving pings in the new version of your app on the schedule that you posted.
However, the schedule in the android app doesn’t seem to follow this same schedule. I am getting pings while the other one is in waiting etc.
[I am testing with both apps set to 45 min interval.]
Since I am just an end user, I can’t say anything about the randomization algorithm behind the android app I hope somebody else who knows more will chime in.
Have you ever used the original TagTime application on windows while also using the android app? If so, did those ping at the same time on the same schedule?
Interesting, I’m assuming the android app uses a different schedule compared to the original program. As I compared the new ping times I got to Daniel Reeves original log file, and they seem to match up.
@dreev is this true that the android app isn’t on the same schedule as the perl scripts?
