Location of bugs list and worklist

[mjphyi]

I'm using Oscar version 1.0.2-beta-1, on SuSe Linux, which I built from a source earlier this year.

I use a Resmed S10 Autosense, and sometimes a Resmed S9.

I have tried to use Oscar to review data from both of these systems, using different profiles for both, and it's not working like I would have expected.

So I'm delving back into a previous career and browsing the source. 

What I'd also like to see is the project bug list, or database or whatever method you are all using to track bugs.
I'd also like to see what's on what I've seen referred to as a "work list", which I presume is the bugs deemed important enough to be fixed first, and also any feature enhancements being planned.

I presume you have this somewhere with read only access for those interested, but I haven't found it yet.

Just today, a second issue arose, and on some level, I think they may be related. Before bothering  you all with a bug report that may already be deemed a feature, it would seem sensible to read the list of known bugs, and planned work list.

Where may I access these documents? 

Michael

[Gideon]

We use Mantis and that is internal to our development team. 2.1.0 testing 4 is the latest non-released version as we are our way to finishing the last items for our next public release which includes major changes to ResMed and PR loader code. I would suggest that you build that code at this time.

Please include any issues you have found in this forum as the OSCAR staff frequently reads this forum and many of our changes have originated here, for the users.

All serious suggestions are considered.

If you have the skills to help us develop the product PM me and let's talk about it. We are always looking.

[mjphyi]

We use Mantis and that is internal to our development team.  2.1.0 testing 4 is the latest non-released version as we are our way to finishing the last items for our next public release which includes major changes to ResMed and PR loader code. I would suggest that you build that code at this time.

Please include any issues you have found in this forum as the OSCAR staff frequently reads this forum and many of our changes have originated here, for the users.  

All serious suggestions are considered.

If you have the skills to help us develop the product PM me and let's talk about it.  We are always looking.

I would normally expect to look in a bug list to see if this was a known problem, or a perhaps a known issue that somebody had deemed a non-problem, however I haven't yet put together an accurate test case, and you have asked, so here goes.

My issue concerns reported time in oscar. I had read on the forum that for resmed machines, time came from the clock settings on the machine, and I see some logic in that (even if I would be irritated if I still worked night shifts).

I use my S10 Autoset at home in Texas, but I had a vacation this summer In Ireland, where I used my older S9. I took with me a laptop with my S10 results on it, and I wanted to use the laptop with Oscar on it to read the S9 results. I set the laptop to use the local timezone, and in case there was an issue with data from 2 different machines, I created a new profile to use with the S9. The new profile also reflected the local timezone.

After using the laptop for about a week, I wanted to compare progress with some S10 results, and when I looked at them, they were split across different days, which was an unwelcome surprise.

I don't have easy access to that data right now, but I believe the times displayed by Oscar are converted to local time.
It's not as simple as that though, and I'm still browsing the source to see what's really going on.

For a test case, you can run Oscar on Unix, and change the timezone. Assuming a US timezone, if you run Oscar from the shell, like

$> TZ=Asia/Dhaka oscar &

you will see the same results displayed and converted to a timezone about 12 hours away from the ones in the middle of the US.

Similarly, when DST ended recently, I had a very short bathroom break that night, and when I reviewed the result, the break was not short at all. The gap in between the 2 sessions had grown by the hour that DST ending had made. Indeed if I watched the time display at the bottom of the graphs, it displayed the local time while the graph X-axis time was the time generated on the S10 (set to CDT and not changed). As I dragged the cursor from left to right, watching the graph X-axis time, and also time at the bottom of the charts, I could see the times in synch from 11PM the previous day until 2AM   where the bottom of page time jumped back to 1AM, and then stays an hour out of synch with "Resmed Time".

I'm guessing that when a session starts, "Resmed Time" is compared to local time, and sometimes adjusted for some of the different times internal to Oscar.

I'm having trouble working out what advantage there could be to this behavior, and so far, I don't get it.

Now i understand when I read on the forum that while Resmed has the machine times setting be the master for its data, not all machine brands do this, so some systems may work better this way.

While I assumed that bugs may be being addressed, is this loader recode that you have in progress a change in code design, or a change to program function?

I'll send you a PM when I've dug a little deeper.

Michael