Home › Forums › Tickstory Lite › New features & suggestions › Couple of suggestions
-
AuthorPosts
-
Hi Tom,
Welcome to the forum – thanks for your comprehensive post. Let me address each one of your points:
– Auto-updating of data: This feature is on the list of enhancements and will be part of the “new generation” Tickstory.
– Data storage: Dukascopy data is already stored in a significantly optimised format as part of their data format changes last year. This includes storing in the manner you described along with utilising the fo;e directory structure to provide the baseline timestamp.
In order to offer optimised data retrieval, we are also working on our own tick database which should sport a competitive compression scheme and allow much faster data management.– MT4 FXT management tool: This is currently on our list of things to do (TICKLITE-15).
– Dukascopy data date-ranges: If you have the dates handy for the instrument date-ranges that would be great. These can be incorporated into the system (TICKLITE-78).
– Candle time starting at 1 minute: Thanks for noting this. A ticket has been raised to investigate this further. I would recommend the workaround you suggested (i.e. selecting one day later) if you want to export data from the beginning of Dukascopy’s dataset. (TICKLITE-79)
– Date format on export screens: Thanks for highlight this. This will be addressed in the upcoming version (TICKLITE-77).
– CSV2FXT conversion using Tickstory export: It could well be some validation that is being done on the volume in MT4. Have you tried to export the data with a volume of 1 and 0 just to rule this out?
– Custom HST/FXT locations: This has been raised as an issue and will be addressed in the upcoming version (TICKLITE-76).
Thanks for your feedback!
Thanks for answers. I’m awaiting new versions.
Meanwhile I’ve read posts about “gaps” in tick data. I think these gaps (missing data) are due to missing .bi5 files. It’s just happened to me today while I was downloading GPBUSD tick data. Some .bi5 files were missing here and there but then the whole September of 2008 was simply “skipped” and not downloaded at all. I had to run download procedure again for GBPUSD and that time September data were downloaded completely. Now I’m checking all the downloaded data of other pairs and already found missing files and whole parts in them, too.
I don’t know for sure what is causing this, it could be network error or a bug. I think (hope) you’re doing several retries in case of download errors before the program is giving up and continues. I’d suggest to make an internal logfile for these errors. When downloading has finished, the program could try downloading the erroneous files in that log again, with extensive retrying attempts, because it seems Dukascopy’s server is sometimes can’t withstand the numerous requests and simply refuses serving the file in question. Further help could be that a year (365 days) will consist of 8760 files (hours). A leap year has 8784 files (hours). If someone is downloading all the data, then you simply can check number of files in a year, for example. Or you can calculate the number of files to be downloaded based on starting and ending date interval. If the number of downloaded file is not matches calculated value, then there must be a download error, it’s worth retrying download procedure. But I think the “logfile of errors” is a better solution.Also, I have tried to copy some data from the log window, but I was not able to do that. Will you please allow copying of log entries from that window? Or is there a way to save the logfile? I have tried to find it in various temp folders, but had no success. I wanted to keep some entries regarding missing files.
I am now working on actual list of starting dates of tick data. I’ll post it here if I’ve finished.
Hi Tom,
Thanks again for the feedback. Regarding retries, yes, Tickstory does attempt to re-download the data up to 3 times at the moment. Do you have the error that you got from the server (screenshot will do)? There have been reports of some network errors however it wasn’t conclusive that this happened on the Dukascopy end. If it’s possible reproduce what you’re seeing then that would be handy. The plan is to have a check for data gaps in the future so this can be done as a post-check (as opposed to logs which can get unwieldy).
At the moment the log viewer does not have the ability to copy/paste entries – this has been put on the list and will be released in the upcoming version (TICKLITE-82).Kind regards.
I have already closed Tickstory since that, and I was not able to copy the error messages out from the onscreen log, so I don’t have it. It’s something like “unable to resolve URL for xxxxxx.bi5 file” or something, so it’s not a numbered error (like 404 or 500 etc.). It’s a network error however, and it seems Tickstory is giving up too early. Of course, it can’t retry forever, but it could tell it about somehow. Like it were write with red letters next to the symbol “Download finished, but not completed. XX files are missing, please retry”. If everything was downloaded correctly, then the usual “…completed” text would be written in black.
I’m trying to download another pair’s data and now I’ll take a snapshot of the error.Hi Tom – That’s right, unfortunately it can’t retry indefinitely and logs aren’t the most ideal way to communicate an issue. This will be revisited in the new version. For the moment however, as per the trouble-shooting manual, the recommendation is to resolve any recurring errors before using your export.
Hope this helps.
I’ve just finished discovering starting dates for each Tickstory pair’s tick data. These could be used as default starting date instead of today’s date. See below:
Format:
PAIR Time (in mql format of yyyy.MM.dd hh:mm)
AUDCAD 2010.02.16 11:00
AUDCHF 2010.02.16 11:00
AUDJPY 2007.03.30 16:00
AUDNZD 2008.12.22 16:00
AUDSGD 2011.11.22 10:00
AUDUSD 2007.03.30 16:00
CADCHF 2010.02.16 11:00
CADHKD 2011.11.28 07:00
CADJPY 2007.03.30 16:00
CHFJPY 2007.03.30 16:00
CHFPLN 2011.11.29 08:00
CHFSGD 2011.11.28 07:00
EURAUD 2007.03.30 16:00
EURBRL
EURCAD 2008.09.23 11:00
EURCHF 2007.03.30 16:00
EURDKK 2007.03.30 16:00
EURGBP 2007.03.30 16:00
EURHKD 2010.10.15 15:00
EURHUF 2011.11.28 17:00
EURJPY 2007.03.30 16:00
EURMXN 2011.12.01 16:00
EURNOK 2007.03.30 16:00
EURNZD 2010.02.16 11:00
EURPLN 2011.11.28 17:00
EURRUB 2011.11.29 06:00
EURSEK 2007.03.30 16:00
EURSGD 2011.11.22 10:00
EURTRY 2011.11.22 10:00
EURUSD 2007.03.30 16:00
EURZAR 2011.12.01 16:00
GBPAUD 2010.02.16 11:00
GBPCAD 2010.02.16 11:00
GBPCHF 2007.03.30 16:00
GBPJPY 2007.03.30 16:00
GBPNZD 2010.02.16 11:00
GBPUSD 2007.03.30 16:00
HKDJPY 2011.11.22 10:00
HUFJPY
MXNJPY 2011.11.28 13:00
NZDCAD 2010.02.16 11:00
NZDCHF 2010.02.16 11:00
NZDJPY 2010.02.16 11:00
NZDSGD 2012.01.26 08:00
NZDUSD 2007.03.30 16:00
SGDJPY 2011.11.22 10:00
USDBRL 2011.11.28 17:00
USDCAD 2007.03.30 16:00
USDCHF 2007.03.30 16:00
USDCZK
USDDKK 2010.10.15 15:00
USDHKD 2010.10.15 15:00
USDHUF 2011.12.01 09:00
USDJPY 2007.03.30 16:00
USDMXN 2010.10.15 15:00
USDNOK 2008.09.28 22:00
USDPLN 2011.12.05 17:00
USDRON
USDRUB 2011.11.28 21:00
USDSEK 2008.09.28 23:00
USDSGD 2008.09.28 23:00
USDTRY 2010.10.15 15:00
USDZAR 2011.11.28 17:00
XAGUSD 2010.11.11 16:00
XAUUSD 2010.11.11 16:00
ZARJPY 2012.01.25 10:00
There are a few dates missing, because Tickstory was not able to download anything in these cases. I guess Dukascopy just has plans for making these pairs available, but there are no tickdata for download at the moment.
It is advisable to re-check these starting dates periodically in the future (especially the ones after 2010-2011), because they might be changed (extended). For example XAUUSD’s starting date has just extended from 2011.05.10 07:00 to 2010.11.11 16:00. I think there will be further extensions regarding new pairs (for example the ones with East-European currencies involved).Hi Tom,
Many thanks for getting back with these details. Given that the date ranges could potentially vary, it sounds like it’s better to prompt with a warning if users try to go beyond but not disallow it altogether.
We’ll figure out how best to implement this in the revamped version.
Kind regards.
Hi Tom,
Thanks for all your suggestions and feedback. A number of your items have been addressed in the latest v0.8 Release Candidate which is currently undergoing testing. If you want to get a hands-on look prior to the official release, please refer to the following post.
If you come across any issues, please let us know.
Regards.
Thanks for the heads up. I’ll peek into it. 🙂
Edit: done…
– It’s not saving main window’s size and position. It’s needed to be pulled and tossed around every time when I start the program.
– Download date format is still english (dd/mm/yyyy). It’s not just the “look”, but for example when I want to give “30” for the day and the month is still on “02” then it won’t allow it and changes day number back to original. It’s ok if I can notice it, but if not, then it could ruin several hours of downloading session because the wrong date… Regular MT4 format would be good (YYYY.mm.dd)
– Export to MT4, Data export tab:
– From date should be the date of the earliest downloaded data (if any). If no data exist yet, then you could use the date from the table I’ve posted yesterday. Also, To date could be the date of latest downloaded data. If no data exist yet, then it could be today’s date.
– Adjust Timezone: put “UTC (Coordinated Universal Time)” by default. While the current default (UTC) Monrovia, Reykjavík is basically the same (GMT+0, no DST), yet it could confuse some users. By default, Dukascopy has GMT+0, no DST on their data.
– Filter duplicate ticks: should be enabled by default as it is more common and is producing less than half sized files (4 GB barrier issue will disappear even for pairs with 2007.03.30 beginning date and today’s ending date). And of course, backtests will be about twice as fast as with duplicate ticks.– Export to MT4, MetaTrader info tab:
– “Load” button forces loading files with .mt4config extension only. However, the TickstoryInfoExpert EA can save files with any name. I have saved the info with a .txt extension and Tickstory was not able to find it, of course. I’d suggest either to put the “.mt4config” extension after the user given filename in the EA or allow loading files with other extensions in TickStory. The first one is the quicker way, the second one needs some checks if the file to be downloaded is a valid Tickstory mt4config file or not.– Export to file:
– It should have the same defaults for dates like in MT4 export.
– There is no field for custom path for the file to be saved. Tickstory is putting the .csv in its own directory. I’d suggest to put the .csv into the downloaded pair’s main directory. Like if it was EURUSD, then .csv would go to in EURUSD directory by default. Of course, user could change that.– Log window: copying from menu is ok, copying by Ctrl+C is ok, copying by Ctrl+Insert (which I’m using the most) is doing nothing.
That’s all for now. I’m currently trying to figure out what are the differences between your .csv and Birt’s .csv
Hi Tom,
Thanks for the additional feedback. These items will be looked into. To respond to somenof your points:
– The date format displayed in the date selection is based on your Windows regional settings (i.e the “short date” format). If you want to make any changes here all you should need to do is change these settings.
– The time-zone selected is GMT-0 (as you noted). The naming for each of the time-zones is sourced from the Windows O/S. XP has a bit of an antiquated naming scheme as you mention. Windows 7 users are presented with a more current naming convention which refers to it more correctly as “UTC”.
Hope this helps!
– Wrong. My country’s date format is NOT english (dd/mm/yyyy). It is yyyy.mm.dd, yet Tickstory’s download date is presented in dd/mm/yyyy, so the solution is NOT changing my windows regional settings.
– I am using Windows 7 currently. In Tickstory it is showing UTC Monrovia, Reyjavík, which is GMT+0, that’s why I’m telling it might be confusing for some.
Hi Tom,
It appears you might be referring to the “Download” date selection screen in which case this item will be addressed. The other export dialogs should be correctly utilising your Windows settings.
As for the wording of GMT, from what you’re saying it appears that there are some other variables within Windows that determine how this is named. Either way, there is unfortunately no scope to change this within Tickstory.
Regards.
-
AuthorPosts
You must be logged in to reply to this topic.