Can I generate OTP secrets by using a hash? Since I learned about one time  pads in last security lecture, I'm quite fascinated how easy the concept is, but how it still is absolutely safe.

Learning from implementing a multi time pad  attack, an OTP is not safe if the key is reused. I understand why this is the case. Also encoding large messages requires a large secret, so I tried to think about, how to solve this. 

This is what I came up with:

Consider we have a Hash Function $H:= A^k \rightarrow A^l$ were $A$ is an alphabet, and $k$ and $l$ are arbitrary lengths. For example  we can use md5 for my purpose. 
Next we have an secret $s_0$ with a length that is not sufficient to encode our message $m$. What if when I run out of characters/bytes of my secret to encrypt my message, I'll take the next characters/bytes from $s_1 = H(s_0)$. I could then repeat that process until I have a sufficient length of the secret $s_0 + s_1 +  ...$.

Also a possible variant would be to generate $s_{i+1}$ by taking the concatenation of the hashed characters of $s_i$. 

Example: $m = thistextistoolongforthesecret$ , $s_0=short$. I can encrypt t with s, h with h, and so on until I have no more characters left for the e. I would calculate $s_1=4f09daa9d95bcb166a302407a0e0babe$ (md5). Then I could use the 4 of $s1$ for encryption of the e.

What are the security implications of this? I have the feeling that this has some serious downside, that eventually will lead to a possible multi time pad attack, but I can't show any reason for that. My knowledge is only superficial, since I only heard about OTP 2 days ago.
Say the adversary is giving you $m_0$ and $m_1$, two arbitrary messages. You draw a random $sk$ and a random $b\gets\{0,1\}$ and output $E_{sk}(m_b)$.

So the adversary takes $ct=E_{sk}(m_b)$ and computes the XOR between the first $n$ bits of $ct$ and the $n$ first bits of $m_0$ (where $n$ is the original key length). Then, he does the same thing for $m_1$, so now he has two options for the secret key, $sk_0$ or $sk_1$. So far everything is good, because they are both equally possible, but now the problems begin: the adversary computes $md5(sk_1)$ and $md5(sk_2)$ and XOR the results with the bits $ct[n+1:n+\texttt{md5-length}]$. With a very high probability, only one of the options will make sense, meaning it would be the bits $m_i[n+1:n+\texttt{md5-length}]$ of some message, so he will know what you encrypted.