Created attachment 26999 [details]
Testcase

unzip testcase.gz
Archive:  testcase.gz
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of testcase.gz or
        testcase.gz.zip, and cannot find testcase.gz.ZIP, period.

The testcase is -gzip- compressed, try running "gzip -d karm.ics.gz".
I get the same error message as you if I try to run unzip...

Works as designed. ktimetracker is designed to be more picky about events that do not have an enddate. It "resumes" these events.

Looking at your testcase, I find
BEGIN:VEVENT
DTSTAMP:20080826T085719Z
X-KDE-karm-duration:0
CREATED:20080529T181519Z
UID:libkcal-327245820.690
LAST-MODIFIED:20080529T181519Z
SUMMARY:Nochwas
CATEGORIES:KArm
RELATED-TO:libkcal-186136581.392
DTSTART:20080529T181519Z
TRANSP:OPAQUE
END:VEVENT

You can stop this behavior by adding 
DTEND:20080529T181519Z
directly after the line containing DTSTART. Or you can use ktimetracker's new feature File|Manage History (or however I called it ;) to add an end date.

A reason for this can be that you aborted karm (at least) twice so the DTEND line could not be written.

Could you try File|Edit History and give feedback?

Hmm. When I open the "Edit history" dialog, it shows an end date for every entry. If I understood you correctly, there should be entries with empty end date fields, right?

Thinking about it some more, I'll have to recheck the "Edit history" dialog after a refresh conversion. IIRC I stopped the running tasks and then opened the dialog.

thanks for stopping my headaches with this comment :)

I justed upgraded again and opened the history immediately without stopping the tasks. For the "... Änderungen" task, there are only two entries in the history. Both entries show an end-date though there is none in the .ics file??

The data is from the same testcase I already attached to this bug.
Here's a screenshot showing the history and the running task.

Created attachment 27132 [details]
"Edit history" showing the end date

Maybe this one is related to/caused by bug #170050?

The scenario of bug #170050 can be the reason, but needn't. Can you compile the latest sourcecode as described at techbase.kde.org?

Is the new/updated code already part of KDE 4.1.2?

If yes, I'd like to wait some more days until it hits my workstation anyway :-)

Dear Thorsten, dear Thomas, thanks for discussing this problem in such detail, it was (partly) helpful for me when I upgraded from KDE 3.5.9 to 4.1.2.  I ran into the same problem, but for me it was not that easy to solve.  My time tracker file has a history of two years, hundreds of tasks, and is 4.8 MB large.  (I'm using it for my whole Ph.D. thesis.)

When I opened the file, too many tasks were running, so that I couldn't stop them individually before they contributed many hours to my total time.  "Stop all" caused KTimeTracker to hang, so I went for the DTSTART/DTEND fix instead, using a Perl script (attached).  Now KTimeTracker could open the repaired file, and converted it to the new format (inserting those X-KDE-ktimetracker fields), but when I closed it and started it again, all those tasks were running again.

As I'm not interested in the history of my tasks but only in the overall time, I chose the lesser evil now, i.e. manually creating a new file with fresh copies of my tasks.

For privacy reasons I won't attach my file, but if you're interested in it for testing, I'm happy to mail it to you.

Created attachment 27905 [details]
Add DTEND entries (same timestamp as DTSTART) where they are missing

Great that you really use ktimetracker. Please mail me this file and I will see why ktimetracker hangs when you stop all tasks.

SVN commit 872139 by tstaerk:

Stopping 300 tasks or more lasts a while. Show a progress bar.
CCBUGS:169660


 M  +10 -1     taskview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=872139

(In reply to comment #16)
> SVN commit 872139 by tstaerk:
> 
> Stopping 300 tasks or more lasts a while. Show a progress bar.

Sounds good!  Now I'm just curious: How long would it actually take to stop all these tasks that were running in my file?  Once I waited for 3 or 5 minutes or so (on a Core 2 Duo 2.0 GHz machine) and then gave up.  But, of course, with such a progress bar, I would have been more patient.

I tested 5 minutes ago :) Join us on irc.freenode.net, channel #kde for user questions and #kontact for KDEPIM development (have to leave soon though). It lasted about 10 minutes in a virtual machine using one 2.4GHz core duo core. Because of the virtualization, your 2.0GHz machine should be a bit faster.

Hmm, Christoph's case supports my feeling that something goes wrong during the conversion, I think it's safe to assume the 300 tasks weren't running when he shut down KDE 3.5... :-)

At the moment I understand what I missed to communicate: This is not a conversion problem. The problem is, when you load an iCal file with events that have no end-date in karm, karm does not restart their timers. ktimetracker does.

Thanks Throsten! When one upgrades from karm to ktimetracker, the filename gets converted from karm.ics to ktimetracker.ics. Would it be possible to stop all "running" tasks after the initial filename conversion to prevent the confusion?

Good point, I hope to be able to do this this weekend.

Here is your workaround if you do not have the latest version from the repository
The workaround for you is to choose clock -> Stop all timers. Then accept that ktimetracker is unresponsive for several minutes.

The latest version of ktimetracker makes it is responsive during "stop all timers" and shows a progress bar.

The conversion between karm and ktimetracker files was necessary because the name ktimetracker is supposed to be stable for a long time, even when the name "karm" will be forgotten. I apologize for the inconvenience.

*** Bug 176004 has been marked as a duplicate of this bug. ***

Now it just happened again: 
I stopped the Ktt which was running from my default installation to give my freshly compiled Ktt a look. The new version started with a task running, that had not been running since noon or so.

Of course not reproducible ...

This happens to me in 4.3.4--no conversion--all new tasks created in ktt.
When I start up ktt (either by login to kde or kill+restart ktt), several random tasks it seems have their timer turned on. I _always_ have the timers stopped before I logout or shut it down. Some of the tasks are already marked as completed.

This is a _really_ annoying bug--esp. when I forget about it, login, and the next day notice that it's added 30hrs to tasks that it shouldn't have touched, I have to go through and figure out how much time to remove from them to fix it.

It happens quite consistently for me.

I still see it from time to time, too. Never detected a pattern though.

I confirm that this bug is annoying and is still present in 4.3.4. Apparently there is no fixed schema of reproducibility, although there is a bigger chance for tasks to reappear that have been active recently. (I have slightly less than  a total of 100 tasks and subtasks in my ktt.ics.) And the chance for random activation is apparently bigger, if ktt had been closed "quickly" or implicitely (by closing session or shutdown for example).

On the other hand, I would like to notice that the following behaviour I observed is quite nice: Activate task ("goto meeting"), log off and close computer, come back, switch on again, and the "goto meeting" task shows exactly 3h25' of wasted time ;-) In clear: It is possible to account for a task without letting the computer and session being running. That is very useful! Karm had problems for example, when my computer ran on battery and went to sleep while inactive. (Negative task times were observed then.)

I am not sure, if this positive new behaviour is reproducible though. It would help, if the designer could point out, what it _should_ be like.

Let me add that when I've observed it, it has nearly always been both a subtask and the corresponding main task that have started timing. Sometimes more than one subtask but usually the main task as well.

Also, it hasn't necessarily always been the most recently used that get started for me. I have one main task that has a subtask per day--and days over a week in the past have been started back up--even though they are marked as completed.

Dirk is right, I should document what behavior is expected on userbase.kde.org.

Anyone who has a self-kompiled ktimetracker: Can you please call it from konsole and paste the output here as soon as you get a task starting at the beginning? Can you also make sure no task is being auto-tracked by desktop?

This happens to me almost every restart, for quite some versions since the karm->ktimetracker changes. Now running 4.3.4 on a debian testing.

I also started from a fresh empty ics file and the same happens. It happens almost every kde login, never tried killing/restart to see if it does the same. Stopped tasks appear to be automatically started.

Is there anyway I can help track this down? I don't have a self-compiled ktimetracker but I am a developer myself, let me know if that's needed, I guess I can compile one.

See bug 229554 for some possibly related data points.

(In reply to comment #30)
Ariel, can you please start from command line and paste the output here and tell which task starts at the beginning?

Entering a negative time change just triggered this bug for me.

Here is the part of the ical file:
BEGIN:VEVENT
DTSTAMP:20100307T122415Z
X-KDE-ktimetracker-duration:-3600
CREATED:20100307T122406Z
UID:libkcal-555779800.689
LAST-MODIFIED:20100307T122406Z
SUMMARY:sub1
CATEGORIES:KTimeTracker
RELATED-TO:libkcal-1872729566.884
DTSTART;TZID=Europe/Berlin:20100307T132350
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

the function that I was about to test (for bug 226915) was changetiMe().

SVN commit 1100411 by tstaerk:

If I changeTime(), I cannot see the enddate() in the editHistoryDialog.
There is something wrong. Making changeTime easier accessible for tests.
CCBUGS:169660


 M  +5 -0      org.kde.ktimetracker.ktimetracker.xml  
 M  +7 -7      timetrackerstorage.h  
 M  +39 -5     timetrackerwidget.cpp  
 M  +5 -2      timetrackerwidget.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1100411

Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I will be closing this bug.