View Issue Details

IDProjectCategoryView StatusLast Update
0003360MediaMonkey (current)Otherpublic2016-12-01 17:32
Status closedResolutionfixed 
Product Version3.0 
Target VersionFixed in Version4.0 
Summary0003360: Use single internet access library instead of TIE + Indy
DescriptionCurrently we use TIE component for only some connections, we should use it for all and thus don't need Indy at all.
TagsNo tags attached.
Fixed in build1304


related to 0003119 closedLudek MediaMonkey (current) Podcasting: many feeds appear empty 
related to 0004976 closedLudek MediaMonkey (current) Extensions: Support for Additional browser header info 
related to 0005373 closedLudek MediaMonkey (current) IE8 triggers connection problems (wininet error) on Vista / Windows 2008 
related to 0005001 closedLudek MediaMonkey (current) Regression: Some podcast feeds no longer work 
related to 0006320 closedLudek MediaMonkey (current) Framework: Retrieve URL data 
related to 0004353 closedLudek MediaMonkey (current) Add hidden config entry to prefer TIE when auto-tag from web 
related to 0004970 closedpeke MediaMonkey (current) Component Updated: New TIEHTTP Release 
related to 0005230 closedLudek MediaMonkey (current) Proxy setting configuration doesn't work as expected 
related to 0005410 closedpeke plugin misc engine improvements 
related to 0001293 closedLudek MediaMonkey (current) Download Manager 
related to 0005437 closedpeke plugin Scrobbler connection problems when IE8 Installed 
related to 0006215 resolvedjiri MediaMonkey (current) Support for auto-proxy configuration via PAC script files 
related to 0011905 resolvedLudek MediaMonkey (current) [Specification Confirmation] About Download Timeout 
related to 0013071 closedLudek MediaMonkey (current) Penny Arcade Podcast fails with SSL error 
Not all the children of this issue are yet resolved or closed.



2007-08-16 10:04

developer   ~0010147

Last edited: 2007-08-16 18:07

The Indy is now used only in CDDBUtils.pas (for CDDB requests).
I would rather wait (with rewriting that code) until we ensure that TIE does not bring any problems to prevent boondoggle (redundant work).

So the priority would be decreased a little.

e.g. I had to modified TIE to be thread safe, it wasn't and could generate an AV as can be seen in some EL files.


2007-11-06 17:53

developer   ~0011812

Also TIE seems to have a problem with HTTP reading for some users on some systems, see

I'm going to temporary use Indy again (only for Amazon reading - as is in MM 2.5) in order to ensure that the problem is caused by using TIE.

Note: I guess we will need to find another HTTP library for MM 3.1 (Both TIE or Indy seem to be buggy)


2009-01-15 20:05

developer   ~0016247

Last edited: 2009-01-15 20:10

Because of and problems related to TIE update (bug 0004970) we should try to find another HTTP library, currently both TIE and Indy (bug 0003119) seem to be buggy and don't satisfy all our needs.


2009-01-15 21:56

developer   ~0016253

I have tested New Tie And no issues with any of example feeds in 0005001 Except few glitches when non Deflate page is loaded it looks that TIE Mixes gzip/gunzip decoding even page is pure HTML/Text.


2009-01-15 23:29

developer   ~0016257

Deferred to MM 3.2


2009-01-24 14:51

developer   ~0016366

Using risk free method I've added few additional headers to TIE Component that should tell servers to better format requested URL.

More details about issue in 0004976


2009-04-24 11:02

developer   ~0017576

Last edited: 2009-04-24 11:11

I was investigating one more thing regarding current implementation and have found that various applications are capable to change internet explorers context menu. Additionally there is always approach where sites made to be seen in MM can return any type of document (like find updates return XML)so that we can internally create object with already existing functions using Active MediaMonkey Skin (Apple store forces usage of iTunes for browsing). But as you already pointed and talked with Jiri long term solution would be to make our own internal browser or even better combination of both.

Have you asked Sven Harazim to send us his HTTP functions for test?

After stable 3.1 we can make meeting to gather all ideas and see how to proceed next.


2009-04-24 11:09

developer   ~0017577

Last edited: 2009-04-24 11:23

Yes, Sven posted
v3.53 is Freeware (Attachment on our FTP)

3.6x is GPL

I have tried the demo and it looks fine ;-)
Many more functions than TIEHTTP and much better written. In addition all the problematic feeds seem to work.


2009-06-23 19:02

developer   ~0018503

I Assign to Myself due the fact that I have fully operational web server on my lan for purpose of testing MediaMonkey Web Functions/Functionality.


2009-06-24 02:43

developer   ~0018506

Reminder sent to: rusty

I agree with Ludek that Alcinoe Common HTTP Functions are much better and cleaner than TIE.

Here is license text from v3.69 Version and I do not see issues with using it.
All files included in the archive are
Copyright (C) 1999-2009 by Arkadia Software Engineering

The component is fully free. You can use it any kind of
software. But you must point to original author in your
program about window or in help file.

Alcinoe component License Agreement.

Use and distribution of the component is permitted provided
that all of the following terms are accepted:

The component is provided "as-is," without any express or
implied warranty. In no event shall the Author be held liable
for any damages arising from the use of the Software.

You can modify and redistribute source code as you wish.

If you do not agree to all of the above terms, you are not
permitted to use the Software in any way, and all copies
of it must be deleted from your system(s).


2009-06-24 20:18

developer   ~0018508

Just a note that we are trying to integrate WebKit (free and open source core of Safari browser) advantaged with platform independence. So we will see later whether Alcione or WebKit would be a solution. In case we will integrate WebKit then we should try to use it for all internet access.


2009-06-24 23:06

developer   ~0018509

Just to note to other dev. team I've been with this user in few crossloop sessions for few hours and even got users account access to No issues on my PC and on other user PC only on one that I was examining, and it looks that TIE is responsible in the way that it can't access wininet libraries. Luckily for now these are isolated issues with I'll try to do more tests in next few days on Alcoine as it is Delphi source.


2009-06-24 23:15

developer   ~0018510

Last edited: 2009-06-24 23:15

v3.53 is Freeware is uploaded to FTP under this bug number


2009-06-25 16:54

developer   ~0018515

Last edited: 2009-06-25 19:50

I've discussed with Peke the pros and cons of WebKit:

The conclusion is that it looks like MM could live without WebKit or any integrated Web Browser, solution is:

MM should offer a common API for the servers like HDTRacks, AllMusic, Amazon etc.
This API will accept kind of XML formatted for MM.

1. All the sites will really looks like integrated to MM UI
2. This will be much more secure, just XML will be posted to the MM
3. We won't need to include probably MBs of WebKit and thus the instalation package won't grow up.
4. We won't be dependent on this third party component (WebKit) and bugs related to the component

EDIT Peke:
5. it is platform independent (as it will use standard IP Packets and Textual/binary data)
6. Can be build up on existing scripting API
7. Can be easily ported to be used on any web platform Server (PHP, ASP,...) or existing Modular Solutions like Facebook, MySpace, Joomla, Mambo, ...
8. Can take Affiliate/Partnership benefits like Apple store is integrated browsing thrum iTunes or MediaGuide in WMP.
9. In future versions it can be Two Way so that MediaMonkey create response messages pages (DLNA, LCD TV Browsers, MediaCenter applications, Web Apps like WAWI, Widgets). Something like Opera browser integrated server into browser


2009-06-25 19:53

developer   ~0018518

Last edited: 2009-08-04 12:57

Some Cons:
1. We will need to make API easy understandable and examples Available in multiple Languages like PHP, ASP,... but keep it similar to existing Scripting API

EDIT by Ludek:
2. We will need to force all the sites we currently have in MM interface (,, eMusic,,, IceCast, SouthCast) to use our API and it could take a longer time.


2009-06-30 14:20

administrator   ~0018531

Last edited: 2009-08-29 01:04

Ludek, Can you clarify what you mean when you say that "MM should offer a common API for the servers like HDTRacks, AllMusic, Amazon etc. This API will accept kind of XML formatted for MM."

It's not realistic to expect these third parties to change the format of their data to match our requirements, but I'm not sure if that's what you're saying.

Edit by Ludek:
There is also possibility to have our own server that would filter and reformat the HTML sites for us and would send us only the formatted XML. This way we don't need to force the third parties like, to use our API, but our server would format the HTML content to our API automatically.

Edit By Peke (Addon for above):
If combined with scripting almost any site could be shown in MM native look, as scripters could easily use MM API to create translation of virtually any site and help us to add more API objects much easily.


2009-07-08 00:11

developer   ~0018550

Last edited: 2009-07-08 01:45

I have made a research of WebKit project today and here are some important links:

1. It’s not a browser. WebKit is a browser engine:

2. The only working version of WebKit that does not use any proprietary Apple libraries seems to be this one:

This WebKit differs from the true Safari webkit as follows:
No support for QuickTime movies.
CFNetwork is replaced by cURL, which implies some reduced functionality and poorer support for concurrent/asynchronous connections.
CoreFoundation is replaced by CFLite, which for the purposes of WebKit should not imply any performance or functionality regression.
CoreGraphics is replaced by Cairo. This generally trails the CoreGraphics implementation, but provides reasonable performance and functionality.

Build steps for the Cairo (all redistributable) are here:

Size of WebKit.dll is 6 MBs, but there are some others DLLs needed like icudt40.dll which takes 14 MBs, but it is one of ICU ( ) libs and we could try to somehow disintegrate it.


2009-08-05 15:50

developer   ~0018615

Last edited: 2009-08-06 19:11

Based on discussion with Jiri we decided to defer WebKit integration until we are platform independent for several reasons.

So for now would be the best to integrate another internet access library that would replace TIE and Indy. The ALCINOE looks fine, I have made a little research and it is well written, all the problematic feeds (that didn't work with TIE xor Indy) seem to work. The main difference is that Alcinoe can use both Windows HTTP Services (WinHTTP) and WinInet, but TIE uses only WinInet. WinHTTP is more secure and robust than WinInet. However, single-user applications that need FTP or gopher functionality, cookie persistence, caching, automatic credential dialog handling, Internet Explorer compatibility, or downlevel platform support should still consider using WinInet. See and for more info.
Mainly this one: seems to be useful.

Another advantage of porting from WinInet to WinHTTP is auto-proxy support, see:


2009-08-06 19:05

developer   ~0018618

Removed dependencies on TIE and Indy internet access libraries, we use Alcinoe for all http access now (podcasting, file downloading, auto-tag from web, file streaming, CDDB queries, OPML directory browsing, etc.)
Tested and I haven't found a regression/problem so far.

Added in build 1300.


2010-03-23 12:37

developer   ~0020068

Last edited: 2010-03-23 12:42

Important note:

I reverted to Indy 10 (Internet Direct) using Windows Sockets 2 for several reasons:
1. I found out that the issues because of we deprecated Indy (e.g. issue 0003119) no longer occurs.
2. It uses windows sockets (lower level then WinInet or WinHTTP) which allows us to use Indy for all internet protocols and schemes (not only HTTP and HTTPS)

Pros of Alcinoe:
+ MediaMonkey.exe is smaller (- 85 KB), because it uses high level WinInet.dll

Cons of Alcinoe:
- it uses WinInet or WinHTTP which is a higher level and restrict Alcinoe to use only HTTP and HTTPS schemes
- it is not unicode ready and ready for Delphi 2010 so I had to modify the code, now it works right
- it is a standalone third party library (not a part of RAD Studio 2010)

Pros of Indy 10:
+ It is unicode ready and integrated to Delphi 2010
+ It uses WinSock2.dll (windows sockets 2) and therefore it supports also the others schemes than http and https
+ Time to compile MediaMonkey.exe is shorter

Cons of Indy 10:
- MediaMonkey.exe is larger (+ 85 KB)

Conclusion: I am going to start MediaMonkey 4.0 test cycle with Indy 10 and in case of any significant problems we can whenever revert to Alcinoe (just under ALCINOE compiler directive)

Indy included in build 1304.


2010-03-23 19:54

developer   ~0020070

Is it possible to create solution for 0004976 under Indy. Like TIE and Alcoine is capable?


2010-12-17 01:09

developer   ~0021878

Closing and no issues with Win 7, IE9, IE8 and all versions from 1304-1335

Re-verified 1335